Third-Party Banner Developer Access

Topic: Third-Party Banner Developer Access
Audience: Staff
Creation Date: October 10, 2014
Author: Anthony Becker

This document describes the basic access requirements for consultants who are contracted for development projects on our Banner systems. It does NOT explicitly cover consultants who perform product-implementation projects, though many of the same principles may apply.

This document also describes the procedures for requesting and assigning the access.

Rationale

SIG and Ellucian personnel who have been contracted to perform development projects on our Banner systems are assumed to have the necessary skills to complete these projects according to industry best practices, and the understanding of basic conventions for developing Banner processes. As such, these persons will be granted full developer access to our TEST Banner systems, and query access to our PROD Banner systems if requested, to the same extent that we would grant such access to UTS employees performing development functions. This access will include, as a minimum, SSH access to the Banner job server, and Internet Native Banner accounts, as described below.

Standards

Development standards

Contracted developers are assumed to have basic knowledge of the Banner naming convention scheme and are expected to follow it. They are also expected to use the appropriate API calls in any code that they develop, whenever possible. They are also expected to provide a source file for any database objects that they create.

We will provide copies of all applicable local development standards documentation to developers, or links to online copies of such (where practical).

• Banner development standards may be found at BannerDevelopmentStandards.

• Workflow development standards may be found in the General Banner Training Resources course of eSpace.

• As additional standards may be developed, they will be added to this list.

As with local developers, a member of the Data Administration team will perform all production installations of objects created by contracted developers.

Data change standards

Changes to Banner data are allowed only under the following circumstances:

• Such changes are made in the TEST system
• These changes are directly related to the contracted development project
• The reasons for these changes are clearly explained in the project documentation
• It is expected that the same changes will be required when implementing the contracted product in the PROD system
• The changes are scripted and the procedure clearly documented so that the Data Administration team may repeat the required procedure in PROD

Changes to PROD data will only be made by the Data Administration team.

Developers are advised to take appropriate measures to back up data being changed, in case it needs to be restored.

Account names

The account names for contracted developers are assigned based on a naming convention that includes part of the company name and part of the person’s last name; for example, “sig_para” or “ellu_orn”. Account names for SIG employees will start with “sig_”;accounts for Ellucian employees will start with “ellu_”. Conventions for other companies will be determined as needed. The length of account names will be between 3 and 15 characters inclusively for the entire account name.

The same account name will be used on all systems where an account is created. The account is defined in RHDS and access to services and servers is defined as attributes, classes, and groups of the account. See the document glossary.

Description of Basic Access

VPN access

Contracted developers will usually be accessing our systems off campus. A VPN account will be created. A VPN profile which grants access to all Banner systems will be used.

Banner server command prompt access

SSH access to servers appropriate for the project will be granted as needed. This will require creation of accounts in RHDS and attributes, classes, and groups that provide access to these servers. Developers will usually be limited to the TEST Banner job server (CNAME bjobtest.sys.oakland.edu).

Access to other Banner servers may be granted if appropriate, and must be approved by the DBA.

Developers will be added to a local group on the job server (to be determined) which will be allowed write access to the “oakland” areas of the Banner code tree, as well as to the dataload area of the code tree. This group will also have read access to the remaining areas of the code tree, and to the banjobs output directory.

Internet Native Banner access

A Banner account will be created on the TEST database for the developer. In addition to the basic classes we grant to all users (BAN_CONNECT_C, BAN_SHOWALLMENU_C), the baseline product classes appropriate to the areas being worked on will be granted; for example, if the developer was contracted to work on an HR project, the classes BAN_PAYROLL_C and BAN_POSNCTL_C will be granted.

By virtue of the SSH access, developers will have access to the password file, which will allow them to obtain the BANSECR password and to assign themselves additional access, as well as direct access to other schemas. We WILL advise them of this fact, and instruct them to take appropriate precautions when modifying data.

A Banner account on the PROD database MAY be created for the developer, if requested; however, beyond the basic classes, only query access to project-related products may be granted. Update access MUST NOT be allowed, unless explicitly approved by the DBA.

Database access

Database connection information (server, port, SID/service name) will be provided to developers, so that they may use the development tools of their choice (e.g. SQL Developer, TOAD, &c) on their own desktops. We will NOT provide such software to them; they must use their own licensed software for this purpose.

The developer’s named account will have the USERS tablespace as default, with unlimited quota on that tablespace only. Additional access appropriate to the project may be added to the named account via roles.

By virtue of the SSH access, developers will have access to the password file, which will allow them full access to any table in any schema of the TEST database via various DBA accounts. We WILL advise them of this fact, and instruct them to take appropriate precautions when modifying data.

Self-Service Banner access

Access to Self-Service Banner for purposes of testing is usually not necessary. The standard procedure for such testing, as practiced by OU staff, is usually as follows: (This will be completed by the department who has contracted SIG or Ellucian)

• Identify a person or persons in Banner whose records meet conditions appropriate to the test
• Create a GOAEMAL record for the person(s) in TEST, using the OAKU email type and the email address of the tester (not the actual email address of the person(s) whose records are being tested)
• In the TEST database, reset the PIN of the person(s) whose records are being tested.
• Login as the person(s) whose records are being tested.

Access to Self-Service Banner (in the TEST database only) MAY be granted for the purposes of Web Tailor Administration or other product tailoring or user roles related to the contracted project. Granting of this access requires the creation of a person record in Banner for the developer in the TEST database. Once the developer has a GrizzlyID, the needed Web Tailor role(s) may be granted.

If all that is needed is a GrizzlyID, we can create one easily by creating an ID using Flexible Registration. However, we do not yet know if this would be sufficient to grant tailoring roles to the ID. If it is not sufficient, we may need assistance from UHR to “hire” the developer as an employee in the TEST database, so that roles such as Finance Data Tailor, Development Officer, &c, may be granted.

Procedures for requesting and assigning access

The Banner Access Request for Vendors form should be completed by the contracting department. This will be submitted (attached) with the Banner Access Request Ticket. The VPN section should be circled / marked to indicate the needed access. An expiration date must be specified; extensions may be requested if needed. The contracting department should include contact information in the Banner Access Request Ticket.

The UTS Database Administration Team will submit a Guest Account request form for the contractor, so that the RHDS account may be created. They will need to collect the information required by that form.

The UTS Database Administration Team will create a UTS Ticket to request the contractor’s VPN access. The Account Name, as specified in the “Account names” section and the expiration date should be provided. This information should be available on the Banner Access Request for Vendors form submitted by the contracting department.