Banner Ethos API: Installation Guide

Banner Ethos API
Installation Guide
Release 9.15
March 2019
Notices and Privacy
Notices and Privacy

© 2019 Ellucian.
Contains confidential and proprietary information of Ellucian and its subsidiaries. Use of these
materials is limited to Ellucian licensees, and is subject to the terms and conditions of one or more
written license agreements between Ellucian and the licensee in question.
In preparing and providing this publication, Ellucian is not rendering legal, accounting, or other
similar professional services. Ellucian makes no claims that an institution's use of this publication
or the software for which it is provided will guarantee compliance with applicable federal or state
laws, rules, or regulations. Each organization should seek legal, accounting, and other similar
professional services from competent providers of the organization's own choosing.
Ellucian's Privacy Statement is available at: www.ellucian.com/privacy.
Ellucian shall have the right to (a) use, store, process, modify, reproduce, distribute and display
customer data, and to grant sublicenses to third parties, for the sole purposes of providing the
software, performing Ellucian's obligations under its agreements with customers and complying with
applicable law or legal requirements; (b) use, store, process, modify and reproduce customer data
for Ellucian's internal business purposes, including development, diagnostic, forecasting, planning,
analysis and corrective purposes in connection with the software, and for otherwise improving and
enhancing the software; and (c) use, store, process, modify, reproduce, display, perform, distribute,
disclose and otherwise exploit in any manner Aggregated Data for Ellucian's business purposes,
including disclosure within its public statements and marketing materials describing or promoting
Ellucian or the software. “Aggregated Data” means any data obtained or generated by Ellucian,
including data pertaining to the software, Ellucian's systems and software, and the use of any of
the foregoing, and includes data derived from customer data, which in all instances (i) does not
identify any individual and (ii) is not attributed or attributable to a specific customer. Aggregated
Data includes data that has been combined into databases which include third party data.
Ellucian
2003 Edmund Halley Drive
Reston, VA 20191
United States of America
Ellucian - Confidential and Proprietary 2

Contents
Contents
Introduction.................................................................................................................................... 7
Known installation issues..............................................................................................................8
API knowledge article numbers.................................................................................................... 8
Hardware requirements.................................................................................................................8
Software requirements.................................................................................................................. 8
Oracle database......................................................................................................................8
Application servers..................................................................................................................8
Middle tier (application server) platforms............................................................................... 9
Ellucian software.....................................................................................................................9
Security setup....................................................................................................................... 10
Release tagging.......................................................................................................................... 10
Java dependencies..................................................................................................................... 10
Open ports in the firewall............................................................................................................11
Deployment of multiple web applications................................................................................... 12
F5 load balancer configuration................................................................................................... 12
Perform the Ethos API DB Upgrade steps..................................................................... 13
GUID Generation........................................................................................................................ 14
GUID Generation Process.......................................................................................................... 14
Identify GUID triggers........................................................................................................... 14
GURTRCK table................................................................................................................... 15
Process considerations.........................................................................................................16
GUID generation process (GURGUID) parameters............................................................. 17
GUID generation report........................................................................................................ 18
GURGUID process logs....................................................................................................... 18
Running multiple GURGUID jobs......................................................................................... 19
Disabling triggers during GUID generation.......................................................................... 19
Limitations while running GURGUID.................................................................................... 20
The Oracle DBMS Scheduler............................................................................................... 20
Terminating the GURGUID process..................................................................................... 21
New Installations........................................................................................................................22
Install Banner Integration API..................................................................................................... 22
Install Banner Student API..........................................................................................................23
Upgrade the application database..................................................................................... 25

Update login.sql...........................................................................................................................25
Verify that the required products are applied............................................................................. 25
Migrate staged files to the permanent directories...................................................................... 26
Unix....................................................................................................................................... 26
Windows................................................................................................................................27
Update the version numbers.......................................................................................................28
Restore original roles for accounts modified.............................................................................. 28

Contents
Customize the WAR file..........................................................................................................29

Unzip the release package......................................................................................................... 29
Prepare the installer....................................................................................................................29
Install into the product home directory....................................................................................... 30
Configure shared settings........................................................................................................... 32
Configure application-specific settings........................................................................................32
Database proxy.....................................................................................................................33
Additional information for Elevate users........................................................................ 33
Database proxy for MEP................................................................................................33
Cross Origin Resource Support (CORS)............................................................................. 33
JMX MBean name................................................................................................................ 34
Location of the logging file................................................................................................... 34
Logging level.........................................................................................................................34
Regenerate the WAR file........................................................................................................ 36
Configure a Web Application Server................................................................................ 37

Configure the Tomcat server.......................................................................................................37
Set system properties on Tomcat.........................................................................................40
Configure Java management extensions............................................................................. 41
Configure the WebLogic server.................................................................................................. 41
Verify WebLogic prerequisites.............................................................................................. 42
Configure WebLogic............................................................................................................. 42
Create a WebLogic machine................................................................................................ 43
Create a WebLogic Managed Server...................................................................................43
Set system properties on Weblogic............................................................................... 44
Create an administrative datasource and connection pool.................................................. 45
Create a Self-Service datasource and connection pool.......................................................46
Deploy the WAR File................................................................................................................ 48

Deploy the WAR file to the Tomcat server................................................................................. 48
Deploy the WAR file to the WebLogic server............................................................................. 49
Setup user access.................................................................................................................... 51

Verify the banproxy database account....................................................................................... 51
Verify Oracle user accounts to connect through banproxy.........................................................51
Define user privileges for API access........................................................................................ 51
Conversion scripts to update current indicators in curriculum.................................................... 52
Test the installation.................................................................................................................. 54
Upgrades....................................................................................................................................... 55
Upgrade Banner Integration API.................................................................................................55
Upgrade Banner Student API..................................................................................................... 56
Upgrading from releases before 9.9..................................................................................58

Contents
List of moved APIs......................................................................................................................58

Manual changes needed for IntegrationApi_configuration.groovy..............................................59
Referencing IntegrationApi_configuration.groovy using environment properties........................ 59
Required Ethos Integration Configuration Changes................................................................... 60
Modify Ellucian Ethos Integration configuration for Student and Integration API
endpoints...............................................................................................................................60
ILP Requirements........................................................................................................................60
Undeploy the existing application..................................................................................... 61

Tomcat......................................................................................................................................... 61
Undeploy the application using the Tomcat Manager web application.................................61
Undeploy application manually on UNIX..............................................................................61
Undeploy application manually on Windows........................................................................62
Undeploy the application using WebLogic..................................................................................62
WebLogic Troubleshooting................................................................................................... 64
Disable WebLogic basic authentication...................................................................................... 64
Change the WebLogic configuration for JPA 2.0........................................................................64
HTTP response code 500 and errors related to PL/SQL in API log...........................................65
Appendix A - Ellucian Messaging Service Installation and Configuration........ 67
Appendix B - Elevate Support............................................................................................. 68

Forms restricted using FGAC..................................................................................................... 68
Courses....................................................................................................................................... 68
Sections....................................................................................................................................... 68
New packages.............................................................................................................................69
Elevate and Banner FGAC and VBS......................................................................................... 69
Guidelines for Oracle user that submits API........................................................................69
Update scripts....................................................................................................................... 70
sgtvintpi_080700.sql....................................................................................................... 70
sgorintgi_080700.sql.......................................................................................................70
sgtvfdmni_080700.sql.....................................................................................................71
sgobfdmni_080700.sql....................................................................................................71
sgorfdpli_080700.sql.......................................................................................................71
sgtvfgaci_080700.sql...................................................................................................... 85
sgtvfbpri_080700.sql.......................................................................................................85
sgobfgaci_080700.sql.....................................................................................................86
sgorfbpri_0080700.sql.................................................................................................... 86
sgorfprdi_080700.sql...................................................................................................... 86
sgorfgbpi_080700.sql..................................................................................................... 88
sgorfdplu_080700.sql..................................................................................................... 89
sgorfbpri_sync_job.sql.................................................................................................... 89
FGAC tips....................................................................................................................................89
Create/activate FGAC policies............................................................................................. 90
Use BANINST1 to run gfvbsaddpol.sql......................................................................... 90
View Policy Data from SQL*Plus......................................................................................... 91
Policy names.................................................................................................................. 91
Drop a policy.................................................................................................................. 91

Contents
Schedule a daily job to populate the business profile................................................... 91

Introduction
Introduction
This installation guide details the steps that are required to install or upgrade Banner Ethos API
9.15.
Banner Ethos API consists of the Banner Integration API application and the Banner Student API
application. Checklists have been provided for new installation steps and for upgrade steps.
Before you install any components of the system, you should review this introductory chapter
thoroughly so you have a better understanding of what you are installing and where you will install it.
Starting with the 9.9 release, all clients must install the Integration API. Clients that also have
Student must also install the Student API.
Table 1:
APIs Application to Install Mandatory DB Optional DB Modules

Modules
Foundation Banner Integration API General Student
Student Banner Student API General and Student
and Banner Integration
API
Recruit Banner Student API General and Student
and Banner Integration
API
FinAid Banner Student API General, Student, and
and Banner Integration FinAid
API
Finance Banner Integration API General and Finance
HR Banner Integration API General, Payroll, and Finance
Position Control

Introduction
Known installation issues

Before you install Banner Ethos API 9.15, refer to Article Number 000044059 on the Ellucian
Customer Center for any Banner Ethos API DB Upgrade issues that were reported after the release
was posted.
API knowledge article numbers

The following articles on the Ellucian Customer Center provide additional information.
• See Article Number 000035640 for information on known issues with RESTful APIs.
• See Article Number 000036446 for the Banner Ethos Integration API Configuration sanity check
script.
• See Article Number 000043988 for information on understanding GUIDs and the GUID
generation process.
Hardware requirements
The application has the following CPU and memory requirements.
Recommended: Quad core CPU with 4 to 8 GB of memory for

the application server
Minimum: Quad core CPU with 4 GB of memory for the
application server
Software requirements
The application has the following software requirements.
Oracle database
The minimum supported version is Oracle Database Release 11.2.0.4.
Application servers
The application is supported on the following application servers.
• Oracle Fusion Middleware 11gR1, 11gR2, and 12c using WebLogic: 10.3.3, 10.3.4, 10.3.5,
10.3.6, and 12.1.3.

Introduction
• Apache Tomcat: 7 and 8.
Middle tier (application server) platforms
The application is supported on the following application server and operating system combinations.
Tomcat (64 bit) WebLogic (64 bit)

Red Hat Linux 6.0 (minimum version) Red Hat Linux 6.0 (minimum version)
Windows Server 2008, 2012 Windows Server 2008, 2012
Solaris 10 Solaris 10
AIX 6.1 (JDK 1.7 SR 10 or later) AIX 6.1 (JDK 1.7 SR 10 or later)
HP UX HP UX: 11iV3 (11.31)
Note: Banner 9.x applications are tested on WebLogic using both the Classic Domain template and
the Basic Domain template. For WebLogic server environments, JPA 2.0 support must be enabled.
WebLogic server does not enable JPA by default. To enable JPA, refer to the Oracle documentation
for the applicable WebLogic server version.
Ellucian software
Depending on the products that are licensed at your institution, the following product upgrades must
be applied.
• Ethos API DB Upgrade 9.15

• Banner DB Upgrade 9.17
• For customers who are on Banner 8x, the following minimum Banner versions are needed,
depending on the products that are licensed at your institution:
– General 8.11
– Student 8.16.1
– Accounts Receivable 8.5.2
– Finance 8.12
– Financial Aid 8.28
– Payroll 8.15
– Position Control 8.15
• For Banner 9x HR customers, the following minimum software versions are required:
– Banner Admin Common 9.3.16

– Banner Human Resources/Payroll 9.3.10
• Customers using Ellucian Mobile and who want to enable the Add Authorization, Calculated
Drop Codes, Online Credits, and Zero Text Book Cost features should install Banner Student

Introduction
Administration 9.3.11. These features are configured through Banner Student Administration 9x
pages.
• EMA (Ellucian Messaging Adapter) 3.0
• Banner Event Publisher (BEP) 2.0.2/2.0.2.1 or 9.1/9.1.0.1
Note: EMA and BEP are needed for clients using APIs asynchronously
• (Optional) INTCOMP 8.0.2.6
Note: INTCOMP 8.0.2.6 is needed for ILP clients using grade-entries API. To access the grade-
entries API that is used to submit mid-term and final grade for a student, you must install the
INTCOMP 8.0.2.6 patch (pcr-000124801_int8000206).
BEP, EMS, and the EMA are required to be able to publish events and change notifications to Ethos
integration.
Note: Before upgrading to this release of Ethos API, Ellucian Elevate Integration clients must check
the Ellucian Product Compatibility Matrix for the versions of Elevate that are compatible with this
release.
Security setup
In order for Self-Service Banner to function properly when PII is enabled, both BANPROXY and
BAN_SS_USER must be exempted from PII processing through the setting on the GOAFPUD form.
Release tagging
Use the following tags for application source code in the GIT repository.
Application Tag
banner_integration_api_app rel-ethosapi-9.15
banner_student_api_app rel-ethosapi-9.15
Java dependencies
Development for Banner 9.x is currently supported on Java 7 only, and Java 1.7.x (64-bit version)
must be installed on the application server before you install the application..
The same version of Java must be used to customize and deploy the WAR file. The JDK bin
directory must be defined in the PATH system property.

Introduction
Note: Java 7 includes security restrictions for Rich Internet Applications. Refer to Article 000030656
on the Ellucian Customer Center for details on Java 7 security restrictions with Liveconnect calls to
Oracle Forms Applet.
Open ports in the firewall

To allow communications between applications, you need to open ports in your firewall.
Procedure
1. Open the firewall ports listed below.
Source Destination Port Purpose

Ethos (AWS Cloud) Banner Ethos API API Port For API requests
Server (DMZ)
• 52.0.163.27
• 50.16.144.60
• 52.0.3.106
Banner Ethos API Banner Application App Listener Port For Banner data
Server (DMZ) Server (Internal) access
Banner Ethos API Banner Database DAS Listener Port For DAS data reader
Server (DMZ) Server (Internal)
2. Optional: If you are setting up Banner to publish business event notifications to Ellucian Ethos
Integration, open the ports listed below.
You can skip this setup if you are implementing only proxy API requests.
To identify these ports, you must plan the servers and ports where you will later install the
Ellucian Messaging Service and Ellucian Messaging Adapter.
Source Destination Port Purpose

Banner Application Ellucian Messaging AMQP Port on BEP Publish BEP
Server (Internal) Service for EEDM integration transactions to EMS
Ellucian Messaging Banner Ethos API API Port For API requests
Adapter Server (DMZ) made by the Ellucian
Messaging Adapter
RabbitMQ 5672 - Secure
5671 - Not secure
The Ellucian Messaging Adapter needs access to the Student and Integration APIs, to
RabbitMQ, and the Internet to access Ethos through HTTPS.

Introduction
Deployment of multiple web applications

The following diagram describes various scenarios of deploying multiple web applications.
Figure 11: Deployment Scenarios
In the first and second scenarios, you can deploy multiple web applications with different WAR file
names on the same or different servers.
In the third scenario, if you want to deploy multiple web applications on the same server, the WAR
file names must be different.
In the fourth scenario, you can deploy multiple web applications with the same WAR file name on
different servers.
F5 load balancer configuration

The application was tested using an F5 load balancer.
It was configured with the following settings:
Load Balancing type = Round Robin

Persistence = Cookie
Note: Other configurations may be supported depending on Network Load Balancing (NLB).

Perform the Ethos API DB Upgrade steps

Some database upgrade steps are common to both Banner Student API and Banner Integration API
applications. These common database upgrade steps must be performed before you upgrade the
database for Ethos API applications. The Database Upgrade procedure that must be performed for
both Integration API and Student API, for both new installations and for upgrades.
See the instructions in the Banner Ethos API DB Upgrade Guide for the common database upgrade
steps. The Upgrade Guide is available on the Ellucian Customer Center.
Recommendation for database partitioning
For improved performance on the ledger-activities API operations, partition the FGBTRND
and FGBTRNH Banner tables based on the FGBTRND_POSTING_PERIOD and
FGBTRNH_POSTING_PERIOD columns.

GUID Generation
GUID Generation
The Globally Unique Identifier (GUID) is used to uniquely identify a resource across integrations.
For existing records in Banner, GUIDs need to be created for the tables which are related to a new
resource used APIs developed for a release.
Before the 9.11 release, the Ethos DB Upgrade process was used to generate GUIDS. The DB
upgrade process was time-consuming as there were large tables for which GUIDs had to be
generated for existing records. During that time, none of the other Banner applications could run as
the database was running in the restricted mode.
To overcome this problem, GUID generation has now been de-coupled from the Ethos DB Upgrade.
A new job has been provided to generate GUIDs for existing records and this new job will run
through GJAPCTL. As the database is not running in the restricted mode, other Banner applications
can also run.
For a comprehensive understanding of GUIDs and for information on the GUID generation process,
see Article Number 000043988 - Understanding Ethos GUIDs in Banner Releases up to version
9.14 on the Ellucian Customer Center.
GUID Generation Process

A new GUID generation process called GURGUID has been developed to generate GUIDs for
existing records in Banner. This process should be run after the Ethos DB Upgrade.
The process will run using GJAPCTL in Banner. As this new process is time-consuming, an Oracle
scheduled job handles the GUID generation. A new process called GURGUDR has also been
developed to track the overall status of the GUID Generation process.
Identify GUID triggers
GUID triggers are created and named according to a specific format. Use an SQL query to identify
triggers.
After the initial GUID generation process has been executed for a table, all existing records will have
a GUID. However, as new records are added to these tables those rows will need GUIDs as well. In
order to ensure all new rows in GUID related tables have GUIDs created, a table trigger has been
created.
These triggers will be named in one of the following formats:
• <product code>T_<table_name>_GUID_TRG (the most common). For example,

GT_GUBINST_GUID_TRG
• <product code>T_<table_name>_DEL_GUID_STMT_TRG
• <product code>T_<table_name>_GUID_EACHROW_TRG
• <product code>T_<table_name>_GUID_STMT_TRG

GUID Generation
GUID triggers can be identified with the following SQL:
select owner, trigger_name, trigger_type, triggering_event, table_name

from dba_triggers
where trigger_name like UPPER('_t\_%guid%\_trg') escape '\'
order by 2;
GURTRCK table
GUID generation through GURGUID is driven by the GURTRCK table. GURTRCK records will be
populated during the Ethos DB upgrade.
A GURTRCK record contains the following columns:
• GURTRCK_TABLE – Specifies the table for which the GUID needs to be generated.
• GURTRCK_OBJECT_TYPE - Indicates the purpose of the record.
– GUID_GEN - GURGUID selects these records for GUID generation

– CONSTRAINT - indicates a constraint that should be disabled during GUID generation.
– TRIGGER - indicates a trigger that should be disabled during GUID generation.
• GURTRCK_OWNER – Specifies the owner of the table for which the GUID needs to be
generated, or the related trigger or constraint.
• GURTRCK_OBJECT_NAME – The name of the package.procedure called for GUID generation
(GUID_GEN), or a trigger name (TRIGGER) or constraint name (CONSTRAINT).
• GURTRCK_OBJECT_EVENT – Specifies whether GUID generation should run in SERIAL or
PARALLEL.
– SERIAL - GUIDs will be generated for all records at once.

– PARALLEL - The GUID generation process checks the number of records in the table
for which GUIDs must be generated and the process also checks the threshold record
(GUREOPT_PARALLEL_THRESHOLD) in the GUREOPT table for the rule name ‘ETHOS
PARALLELISM’(GUREOPT_RULE_NAME). If the number of records exceeds the threshold
record defined in GUREOPT, then the GUIDs will be generated using parallel threads and
the number of parallel threads is defined in GUREOPT_PARALLEL_THREADS in the
GUREOPT table.
To query the values, use the following SQL:
SELECT GUREOPT_PARALLEL_THRESHOLD, GUREOPT_PARALLEL_THREADS

FROM gureopt
WHERE GUREOPT_RULE_NAME = 'ETHOS_PARALLELISM';
To update the values, use the following SQL:
EXECUTE gokguid_util.set_parallel(
p_parallel_threads => 8,
p_parallel_threshold => 1000000);
• GURTRCK_ORIG_OBJECT_STATUS – Specifies the original status of the object.

GUID Generation
– The value is always ‘NOT_PROCESSED’ for the GUID generation.

– For CONSTRAINT or TRIGGER rows, the default value will be NA indicating that the
status of the trigger or constraint will not be modified during GUID generation. If the value
is NULL, then GURGUID will disable any enabled trigger or constraint and set the value
to ENABLED. If the trigger or constraint is disabled then the status is set to DISABLED.
This value is used to determine whether a trigger or constraint needs to be re-enabled after
GUID generation is complete. After GUID generation is complete, this value will be set to
NA for all TRIGGER or CONSTRAINT rows.
• GURTRCK_CURR_OBJECT_STATUS – Specifies the status of the GUID_GEN process.
– NOT_PROCESSED - The initial status.

– IN_PROGRESS - The status after the job starts to run.
– GUID_GEN_COMPLETE - The status after the job successfully completes GUID generation
for that table.
– ERROR - If any error occurs during GUID generation for this object, then the status will be
updated to ‘ERROR’.
– NA - The value for all TRIGGER or CONSTRAINT rows.
– NULL - This specifies that TRIGGER or CONSTRAINT rows should be analyzed, either to
be enabled or disabled. This is set to NULL when the GURGDTC process is run.
See the Banner Ethos API Handbook for information on which API maps to which GUID table.
The data in GURTRCK and GUREOPT is delivered as part of the upgrade and normally does not
need to be modified. You can make some alterations such as the addition or removal of TRIGGER
and CONSTRAINT definitions to improve performance.
Warning! There is a known Oracle Bug when performing parallel processing while the database is
in a restricted mode.
If you are running in restricted mode, you should set the number of parallel processes to 0 to ensure
you do not experience this situation. This is the same issue that you may have encountered running
parallel and restricted with DBEU. This value can be updated with the following SQL statement:
EXECUTE gokguid_util.set_parallel(p_parallel_threads => 0,

p_parallel_threshold => 1000000);
Process considerations
As a part of this upgrade a new role has been created; BAN_DEFAULT_GUIDGEN_M. This role is
assigned to the new objects associated with GUID generation (GURGUDR, GURGUID, GURGDTC,
and GURGDJK). The g_create_guidgen_m_01.sql through g_create_guidgen_m_05.sql scripts are
used to create the role and grant the necessary privileges. The new objects are all assigned to the
BAN_ETHOS_C class.
Due to the nature of these jobs, no user has been assigned access to the jobs with a direct grant
or through the BAN_ETHOS_C class. Review the nature of the jobs and assign the ‘super user(s)’
to the objects directly or to the class. These jobs are generally reserved for those users who have
a technical knowledge of the system and understand the ramifications of running these type of

GUID Generation
‘infrastructure’ jobs. See the Banner General Security Administration Handbook for information
related to granting access.
Because there is a new role associated with these objects, you will notice on the GSASECR /
Classes tab that the Class is ‘Out of Sync’. Ensure that you click the Synchronize or Synchronize
All button on the GSASECR / Classes tab to ensure that after the object(s) or class, has been
assigned to users, the roles are properly granted. If you do not synchronize the class, then you may
see a Role Not Granted error when trying to run the job(s).
For additional information associated with the GUID generation process, see the Banner Ethos API
Handbook.
GUID generation process (GURGUID) parameters
The parameters for the GUID generation process (GURGUID) can be entered in the GJAPCTL
screen in Banner.
Specify the following parameters for the GURGUID process:
Enter GUID Generation Method
Values:
• S - Serial
– Updates all of the GUIDs in the related tables in one ‘execution’.

– This means that multiple jobs will not be spawned through DBMS_SCHEUDLER for that
table.
– Most tables are processed using the SERIAL method.
– Shadow tables will always be processed using the SERIAL method.
– Shadow tables (including GORGUID) are generally those tables with a large number of
rows.
– If the shadow table in GURTRCK is accidentally marked as PARALLEL, then the job will
only be picked up if the parameter indicates PARALLEL; however, the actual generation will
still be processed using the SERIAL method.
• P - Parallel
– Non-shadow tables with a large number of rows that have the GUID column residing in
them are typically processed with the PARALLEL method.
– Running in the PARALLEL mode means that there will be multiple jobs (based upon the
number of parallel threads defined in GUREOPT) spawned through DBMS_SCHEDULER,
but only if the total number of rows in the table exceeds the parallel threshold.
– Each spawned job will process individual ‘chunks’ of the table (based upon parallel
threshold defined in GUREOPT). Each ‘chunk’ will be the number of rows divided by the
number of parallel threads.
– In most cases this is a faster method. However, if desired you could change the PARALLEL
designation in GURTRCK to SERIAL and run them in that manner.
– SERIAL jobs cannot be changed to run in PARALLEL mode.
The values are case-sensitive, only upper-case values are accepted.

GUID Generation
Default: S
Specify the following parameters for the GURGUID process:
Module(s) for GUID Generation

Values:
• S - Student
• G - General
• P - Payroll
• N - Position Control
• F - Finance
• R - Financial Aid
• T - Accounts Receivable
• % - For all available modules
The values are case-sensitive, only upper-case values are accepted.
Default: %
The process can be run for a single module , or it can be run for multiple modules by duplicating the
record using Record>Insert and selecting Duplicate and specifying another module.
Debug (Y/N)
To specify whether a GUID generation report is to be run.
GUID generation report
The GURGUDR process is used to check the progress of GUID generation.
As GURGUID is a long-running process, a separate Banner JobSub process, called GURGUDR,

can be run to report on the progress of GURGUID. The GURGUDR process queries the GURTRCK
table to report on which tables GURGUID has completed and which ones are not yet processed. It
provides a list of those tables. At the end of the report, it also displays an overall percent complete
for GURGUID. The output of the report is in the form of a .lis file.
The GURGUDR process can be run while GURGUID is also running, or it can be run at any
other time. It may be useful to run this job to check on the progress of GUID generation, before
running GURGUID to understand what tables are processed and which ones are not. If most of the
tables that have not yet been processed are in the same Banner module, then it may help to run
GURGUID only for that module.
GURGUID process logs
The run log files for the GURGUID process are written to the GUROUTP table.
From the 9.12 release, the log files for the GURGUID process are written to the GUROUTP table
instead of on the database server for the GURGUID job.

GUID Generation
A SQL query can be used to find the log output:
select guroutp_one_up_no, guroutp_line

from guroutp
where guroutp_one_up_no = your-GURGUID-jobsub-number
order by guroutp_one_up_no, guroutp_file_number, guroutp_seq_no;
Running multiple GURGUID jobs
It is also possible to run multiple GURGUID JobSub processes at the same time. This can be done
to complete the GUID generation process faster.
It is possible to submit the GURGUID job multiple times; one time for each module, or one job to
perform all modules. Running GURGUID multiple times will generally decrease the overall elapsed
time for completing the jobs. The GURTRCK table keeps track of what processes have not yet run,
which ones are in progress, and which ones have completed successfully. Therefore, if you run the
job multiple times there is no concern for re-processing an individual table.
The number of jobs actually executing at the same time is controlled by the configuration of
DBMS_SCHEDULER in and the number of gurjobs instances.
Example 1: First submit the initial GURGUID job for all modules, use the ‘%’ value for the Module(s)
for GUID Generation parameter. Then submit a second (or subsequent) job using the same ‘%’
value for that same parameter. When multiple GURGUID jobs are running at the same time, each
job will simply process whatever table is not yet in progress.
Example 2: First submit the initial GURGUID job for specific modules that you want to process,
‘S, F’ for Student and Finance modules. Then submit a second (or subsequent) job for different
modules requiring processing, ‘P, G’ for Payroll and General modules. Each GURGUID job would
then only process the specified modules but would be running at the same time.
Example 3: You must process GUID generation for both the SERIAL and PARLLEL methods, so you
may want to submit one job for all modules using the SERIAL method, and then another job for all
modules using the PARALLEL method.
After a table has processed successfully through GURGUID and GURTRCK has been updated to
indicate that (GURTRCK_CURR_OBJECT_STATUS = GUID_GEN_COMPLETE), then the table
will not be processed again. This means that with subsequent releases you can select ‘%’ for all
modules and it will only process table with newly defined GUID’s and not everything again.
Disabling triggers during GUID generation
To speed up the execution of the GUID generation process, you can disable the triggers on the
tables for which GURGUID generates GUIDs.
However, because GURGUID can be run while normal Banner operations are occurring from
Banner INB or Banner Admin pages, the triggers should remain enabled to allow normal Banner
operations to process as usual.
To disable triggers, a separate Banner JobSub process, called GURGDTC can be run which will
mark the rows in the GURTRCK table to allow triggers to be disabled as each table is processed in
GURGUID.

GUID Generation
Warning! By default, triggers will remain enabled when executing GURGUID. So the use of the
GURGDTC process is only recommended for testing in a test environment and NOT in a production
environment.
When GURGUID runs, it will then disable any triggers listed in GURTRCK for the given table, run
GUID generation on that table, and then re-enable triggers for that table before processing the next
table in the same way. This means that triggers are only disabled for as long as it takes GURGUID
to process the given table. However, some tables can be large with many millions of rows of data
and could take several hours for GURGUID to complete.
When GURGUID is complete, it will leave the trigger rows in GURTRCK marked so that triggers will
be enabled automatically for subsequent runs of GURGUID. This is to prevent triggers from being
disabled by default any time GURGUID is executed. The reason for this is to prevent unexpected
things from happening or prevent expected things from not happening during normal Banner INB
operations while GURGUID is also running.
While executing GURGUID with triggers enabled by default, GUID generation may take longer to
complete, but as triggers fire due to GUID generation, the activity dates and user id should remain
unchanged.
Limitations while running GURGUID
It is recommended that you do NOT run multiple Banner update batch jobs on the same table at the
same time because of potential errors.
Due to limitations in Banner, running multiple Banner update batch jobs on the same table at the
same time could lead to errors which will terminate the batch jobs. Operations from INB or a Banner
Admin page during a Banner update batch job are less likely to generate errors because updates
are usually made for a single row of data. If an error does occur, resubmitting the INB/Admin page
operation should work.
This limitation particularly applies to the JobSub GUID generation (GURGUID) process. If an error
does occur, the GURGUDR progress report job can be run to illustrate the status of the tables
affected by GURGUID. A simple query of the table from the progress report that GUID gen was
working on to count the number of rows with null GUID values should reveal that there are still rows
with null GUID values. A re-run of the GURGUID process would then continue with the affected
table, to complete the GURGUID process.
The Oracle DBMS Scheduler
The GURGUID process is a Banner JobSub process that uses the Oracle DBMS Scheduler to run
GUID generation.
GURGUID uses the GSUBSQL process in Banner JobSub to execute a database package, which
in-turn schedules and immediately starts an Oracle DBMS Scheduler job. This DBMS scheduler
job is what executes the GUID generation process. Therefore, the GURGUID JobSub process only
takes a few seconds to execute in Banner JobSub, but the GUID generation process continues
through the DBMS Scheduler as a long-running process until GUID generation is complete.

GUID Generation
Terminating the GURGUID process
The GURGUID process can be a long-running process. It can be terminated, and processing can be
continued later according to your schedule.
To terminate the GURGUID process, a separate Banner JobSub process, called GURGDJK, can
be run against the database. This will terminate all GURGUID jobs running in the Oracle DBMS
Scheduler, in addition to any jobs that have been scheduled to run but are not yet running.

New Installations
New Installations
Use the checklists to complete the required steps for a new installation of Banner Integration API
and Banner Student API.
Install Banner Integration API

The following checklist is for a new installation of Banner Integration API 9.15.
1. Upgrade the application database on page 25
• Update login.sql on page 25

• Verify that the required products are applied on page 25
• Migrate staged files to the permanent directories on page 26
– Unix on page 26
– Windows on page 27
• Update the version numbers on page 28
• Restore original roles for accounts modified on page 28
2. Customize the WAR file on page 29
• Unzip the release package on page 29

• Prepare the installer on page 29
• Install into the product home directory on page 30
• Configure shared settings on page 32
• Configure application-specific settings on page 32
– Database proxy on page 33

– Cross Origin Resource Support (CORS) on page 33
– JMX MBean name on page 34
– Location of the logging file on page 34
– Logging level on page 34
3. Regenerate the WAR file on page 36
4. Configure a Web Application Server on page 37
• Configure the Tomcat server on page 37
– Set system properties on Tomcat on page 40

– Configure Java management extensions on page 41
• Configure the WebLogic server on page 41

New Installations
– Verify WebLogic prerequisites on page 42

– Configure WebLogic on page 42
– Create a WebLogic machine on page 43
– Create a WebLogic Managed Server on page 43
– Set system properties on Weblogic on page 44
– Create an administrative datasource and connection pool on page 45
– Create a Self-Service datasource and connection pool on page 46
5. Deploy the WAR File on page 48
• Deploy the WAR file to the Tomcat server on page 48

• Deploy the WAR file to the WebLogic server on page 49
6. Setup user access on page 51
• Verify the banproxy database account on page 51

• Verify Oracle user accounts to connect through banproxy on page 51
• Define user privileges for API access on page 51
7. Test the installation on page 54
Install Banner Student API

The following checklist is for a new installation of Banner Student API 9.15.
1. Install Integration API before installing Student API. Follow the steps in Install Banner
Integration API on page 22

– Unix on page 26

• Configure shared settings on page 32

New Installations
• Configure application-specific settings on page 32
– Database proxy on page 33

– Cross Origin Resource Support (CORS) on page 33
– JMX MBean name on page 34
– Location of the logging file on page 34
– Logging level on page 34
5. If you are installing Student API on the same Web Application Server where Integration API is
installed, you only need to Set system properties on Tomcat on page 40 or Set system properties
on Weblogic on page 44.
If you are installing Student API on a different Web Application Server from where Integration API is
installed, you need to complete all the steps to Configure a Web Application Server on page 37
for either Tomcat or Weblogic.

7. Setup user access on page 51
• Verify the banproxy database account on page 51

• Verify Oracle user accounts to connect through banproxy on page 51
• Define user privileges for API access on page 51
• Conversion scripts to update current indicators in curriculum on page 52

Upgrade the application database

This section details the steps to upgrade the application database for Integration API and Student
API. For Banner Integration API, these steps need to be run in the integration-api-91500u
directory and for Banner Student API, these steps need to be run in the student-api-91500u
directory.
Update login.sql
You must edit login.sql to update the schema owner’s default password and to specify the path
to create log files.
Procedure
1. Replace the #UPDATEME# string with the value of a particular schema owner’s password in your
environment. Make this update in your environment for each Banner schema owner.
2. Set the value that gets assigned to splpref.
The value can be set to the ORACLE_SID or to a directory name. Your options depend on the
operating system.
The splpref variable defines the file prefix that the installation process uses to generate
listings or intermediate SQL routines. This feature allows you to segregate the generated output
when the stage must be applied to more than one instance.
Verify that the required products are applied

You have to check and verify that all prerequisite products are applied to the environment.
Procedure
1. Invoke SQL*Plus and run the following procedure:

sqlplus /nolog @ruappready
2. Review the ruappready listing.

Migrate staged files to the permanent directories

This release provides migration scripts for Unix and Windows platforms. These scripts expect your
directory structure to match the directory structure created by the Banner installation process. If you
choose a different directory structure, you must modify the scripts.
The release does not include migration scripts for other platforms due to their highly customized
structures. You can, however, use the scripts as a starting point for writing your own migration
scripts.
Unix
To run the migration script in the background on a Unix platform, perform the steps in this section.
About this task
A .txt file lists all files that must be deleted from your permanent directories, and all files that should
be copied from the staging directory to your permanent directories. The destination is indicated in
UNIX format. The format is different on other platforms.
• For Banner Integration API: genmigr.txt

• For Banner Student API: stumigr.txt
A .shl file does the appropriate removes, copies, and links. The local LN variable at the top of the
file determines the type of links that are used in the migration. If you want to use symbolic links, set
LN=‘ln -s’ so that the command ${LN} file $BANNER_HOME/links is translated to ln -
s file $BANNER_HOME/links. If you want to force the removal of any existing targets before
linking files, set LN=‘ln -f’.
• For Banner Integration API: genmigr.shl

• For Banner Student API: stumigr.shl
Procedure
1. Ensure that the directory path names in the .shl file are correct.
2. Ensure that the environment variable $BANNER_HOME in the .shl is set to the appropriate
directory.
3. Sign on to an operating system account that has write permission into the target Banner
directories.
4. If you are a cshell user (your operating system prompt is a percent sign), enter sh and press
Enter to enter the Bourne shell.
5. Navigate to the staging directory for the product.
6. Run the migration script as follows:
• For Banner Integration API: sh genmigr.shl >genmigr.log 2>&1 &

• For Banner Student API: sh stumigr.shl >stumigr.log 2>&1 &

7. If you were a cshell user and want to return to that mode, press CTRL-D or enter exit. Then
press Enter.
8. Review the .log file. This file contains the results of the migration.
Note: Even if your directory structure matches the baseline perfectly, some link commands will
fail (that is, where the link currently exists). Other link errors might indicate that you had two
copies of an object when the migration script was executed. This condition must be corrected.
The duplication is probably between links and the product subdirectory.
Windows
To run the migration script on a Windows platform, perform the steps in this section.
About this task

A .pl file does the required deletes and copies.
• For Banner Integration API: genmigr.pl

• For Banner Student API: stumigr.pl
Procedure
1. Check the value of the BANENV environment variable by executing the SET command from the
DOS prompt.
a) If the value of BANENV is REG, the value used for BANNER_HOME will be taken from the
registry entry: HKEY_LOCAL_MACHINE\SOFTWARE\BANNER\BANNER_HOME.
b) If the value of BANENV is ENV, the value used for BANNER_HOME will be taken from the
environment variable BANNER_HOME.
2. Ensure that the directory path names in the .pl file are correct.
3. Sign on to an operating system account that has write permission into the target Banner
directories.
4. Navigate to the staging directory for the product.
5. Run the migration script as follows:
• For Banner Integration API: perl genmigr.pl >genmigr.log 2>&1

• For Banner Student API: perl stumigr.pl >stumigr.log 2>&1
6. Review the .log file.
This file contains the results of the migration.

Update the version numbers

To insert the release version numbers into the Web Application (GURWAPP) and the GURWADB
tables, perform the following steps.
Procedure

sqlplus general/password
start versionupdate
2. Review the versionupdate listing.
Restore original roles for accounts modified

Run an .sql to restore the original roles for those accounts modified by scripts run at the beginning
of this upgrade.
About this task
Warning! If you are running upgrades in parallel, do NOT run this part until you have finished all of
your upgrades. The reason is that several accounts are used by all upgrades. If they do not have
the DBA role as a default role, this script will reset their privileges so DBA is not included. This could
have adverse effects on the other upgrades.
Procedure
• For Banner Integration API: sqlplus /nolog @intapiresroled

• For Banner Student API: sqlplus /nolog @stuapiresroled
2. Review the intapiresrole and stuapiresrole listings.

Customize the WAR file

The release package must be unzipped and the WAR file must be customized for your institution.
The name of the release package is release-applicationname-9.15.zip. Where

applicationname is the name of the API application, IntegrationApi or StudentApi. The
release packages were moved to the $BANNER_HOME\general\java and $BANNER_HOME
\student\java sub directories during the database upgrade.
Note: JDK 1.7 must be installed on your system.
Unzip the release package

To unzip the release package into a temporary directory, perform the following steps.
Procedure
1. Log in to the application server platform.
Note: You must have a valid application server account to deploy into the application server
container (Tomcat or WebLogic).
2. Create a temporary directory. For example:

mkdir $HOME/ban9temp
3. Locate the release package, either $BANNER_HOME\general\java\release-
IntegrationApi-9.15.zip or $BANNER_HOME\student\java\release-
StudentApi-9.15.zip.
4. Transfer this file in binary mode using File Transfer Protocol (FTP) file into the temporary
directory. For example:
$HOME/ban9temp
5. Unzip the release package into the temporary directory.
Prepare the installer

To prepare the installer, perform the following steps.
Procedure
1. Change the directory to the installer directory:

cd installer
2. Run the ant command, which will build the installation tool.

Note: For Unix, make sure the ant file is executable. For example, chmod +x ant.
Example:
ban9temp $ cd installer
ban9temp/installer $ ./ant
The message Build successful confirms a successful build.
Install into the product home directory

The product home directory supports the configuration and creation of a deployable WAR file.
Although Banner 9.x web applications are modular and are installed independently, they share a
common configuration. The package provides a common installer that creates consistent product
home directory structures for all Banner 9.x applications.
About this task

Within a particular environment, you should place the product home directories for Banner
9.x applications in sibling directories. For example, the following directory structure includes
product home directories and a shared_configuration directory that support a common test
environment.
TEST/
|--> applicationname/
|--> Catalog/
|--> shared_configuration/
Where applicationname is the name of the API application, IntegrationApi or StudentApi.
A product home directory is created for each deployment. For example, the home directory that is
used for the application within a test environment is different than the home directory that is used
for the production environment. When you are supporting different environments for multiple home
directories for the same solution, this structure provides the necessary configuration, release level,
and custom modification flexibility.
The following directory tree illustrates the product home directory that is created for the test
environment:

In addition to the application’s product home directory, a separate shared_configuration home

directory contains cross-application configuration for the test environment. This directory holds the
banner_configuration.groovy file, which contains the shared JNDI datasource configuration.
To install the installer into the product home directory, perform the following steps:
Procedure
1. Ensure that the installer is prepared using ant.

2. Use the installer to install the release file into the product home directory.
Note: Your current working directory must be in the installer directory (ban9temp/installer)
before executing the following commands.
On Unix:
$ bin/install home
On Windows
> bin\install home

3. When prompted, enter the full path of the application home directory.
The application will be installed within the current subdirectory within this home directory and
the previous release will be archived.
On Unix:
[]: Current_home_directory/banner_test_homes/applicationname
Where applicationname is the name of the API application, IntegrationApi or

StudentApi.
On Windows:
[]: c:\banner_test_homes\applicationname

StudentApi.

4. Enter the full path of the shared_configuration home directory.

Banner 9.x applications that refer to this home directory share this configuration file.
On Unix:
[]: Current_home_directory/banner_test_homes/shared_configuration
On Windows:
[]: c:\banner_test_homes\shared_configuration
Note: If an identified home directory or the shared_configuration home directory does not exist,
the installer creates it. The name of a product home directory is not restricted. You can name it
when prompted by the installer.
Configure shared settings

The shared_configuration home directory contains a cross-application configuration file called
banner_configuration.groovy. You can change settings in this file.
You can optionally change the datasource name in the configuration file to point to the JNDI
datasource that is configured in your application server. For example, jndiName ="jdbc/
bannerDataSource" is the default configuration. You can change this to match the JNDI
datasource name in your environment. If you change the jndiName, you must regenerate the WAR
file, even if you are using an external configuration.
Transaction timeout value
The banner_configuration.groovy file also contains the banner.transactionTimeout

property. You can edit the file and change the value for this property to alter the timeout, indicated in
seconds, for the API application. The recommended value is 60. Restart the managed application
server for the new value to take effect.
Configure application-specific settings

The applicationname\current\instance\config directory contains the
applicationname_configuration.groovy file. Where applicationname is the name of

the API application, IntegrationApi or StudentApi. This application-specific configuration file

contains settings that you can customize for your specific environment.
Database proxy
Set the apiOracleUsersProxied setting to true. When the setting is set to true, API database
requests are sent through the bannerDataSource.
Note:
When apiOracleUsersProxied is disabled (value is false), user audit trails are the username
that is configured for bannerSsbDataSource.
For more information about the configuration changes, refer to the

applicationname_configuration.groovy.example file that is shipped along with this
release. Where applicationname is the name of the API application, IntegrationApi or
StudentApi.
Additional information for Elevate users
All API user profiles are present in the GORFBPR table. With changes effected in the 9.12 release,
this prevents some Banner data updates through Elevate. Remove the API user that is used
for Elevate integration, from the GORFBPR table. This is the API user defined in Elevate to
communicate with Banner through the APIs.
Database proxy for MEP
If you are installing the product in a Multi-Entity Processing environment, change the database
proxy setting.
Set the apiOracleUsersProxied setting to true in the

applicationname_configuration.groovy file. Where applicationname is the name of the
API application, IntegrationApi or StudentApi.
Then restart the StudentApi or IntegrationApi application if it is already running.
Cross Origin Resource Support (CORS)
By default, browsers do not allow JavaScript or Java applets to call APIs outside the origin
site's domain. The cors.enabled setting can be used with the cors.allow.origin.regex
setting to enable calls to APIs from client browsers if the origin sent in the request matches the
cors.allow.origin.regex pattern set. This is accomplished by echoing the received matching
origin in the allowed origin field of the response header.

JMX MBean name
The name that is used to register MBeans must be unique for each application that is deployed
into the JVM. This configuration should be updated for each instance of each application to ensure
uniqueness.
jmx {
exported {
log4j = "applicationname-log4j"
} }
Location of the logging file
Log4j is the common logging framework used with applications that run on the Java Virtual Machine.
You can configure the location at which the log file is saved.
For more information about the Log4j settings, see http://docs.grails.org/2.5.0/guide/conf.html.

The configuration file includes documentation on various elements that can be modified depending
on your environment.
The following example shows how to configure the location where the log file is saved:
loggingFileDir = System.properties['logFileDir'] ?
"${System.properties['logFileDir']}" : "target/logs"
logAppName = "applicationname"
loggingFileName = "${loggingFileDir}/${logAppName}.log".toString()
The following example shows how to override the log file directory properties:
export JAVA_OPTS = "-DlogFileDir=/PRODUCT_HOME/"
The output log file location is relative to the application server to which you are deploying.
Logging level
The root logging level is pre-configured to the ERROR level. Multiple class or package level
configurations, by default, are set to a status of off. You can set a different logging level for any
package or class. However, configuration changes for logging take effect when the application is
restarted.
For example:
case 'production':

root {
error 'appLog' //change the log level here with the
appropriate log level value.
additivity = true
}
Note: Changing the logging level to DEBUG or INFO produces very large log files.
Changes to the applicationname_configuration.groovy file take effect after the application

is restarted. Where applicationname is the name of the API application, IntegrationApi or
StudentApi.
Alternatively, you can use JMX to modify logging levels for any specified package or class, or even
at the root level. When using JMX, the logging level changes only affect the running application.
When you restart the application, changes that you made using JMX are lost.
For more information on JMX configuration, see the Configure Java Management Extensions
section.

Regenerate the WAR file
Regenerate the WAR file

After the shared and application-specific configurations are complete, the application WAR file can
be regenerated to include your customizations and application-specific settings. The WAR file can
then be deployed into your specific application server. The systool is used to create the WAR file.
About this task

The application uses the configuration files in the WAR file unless you override them by
specifying the environment variable. For example, you can override the location of the
banner_configuration.groovy file by setting the environment variable as follows:
BANNER_APP_CONFIG=/path/to/banner_configuration.groovy
Procedure
1. Change your current working directory to the product home directory: applicationname/
current/installer. Where applicationname is the name of the API application,
IntegrationApi or StudentApi.
2. Run the ant command which builds the systool module.
For UNIX systems, ensure that the ant file is executable. For example,
chmod +x ant
For example,
$ cd applicationname/current/installer
applicationname/current/installer $ ./ant

StudentApi.
3. Use the systool module to create the WAR file.
On Unix:
$ bin/systool war
On Windows
> bin\systool war
The WAR file is created in the applicationname/current/dist directory. Where

applicationname is the name of the API application, IntegrationApi or StudentApi.
What to do next
You can use external configuration files by setting system properties, although the configuration files
are included in the WAR files to make the WAR file self-sufficient. See the Configure the Tomcat
Server and Create a Web Logic Server sections for more information.

Configure a Web Application Server

You can configure a web application server such as Tomcat or WebLogic and deploy the WAR file
on the web application server. It is recommended that you can secure the web application traffic by
using standard TLS encryption, which is supported by the application server software.
For more information about enabling HTTPS support for web applications, see your application
server documentation.
Configure the Tomcat server

You can configure the Tomcat server and then deploy the WAR file to the Tomcat server.
Before you begin

Ensure that you download and install either Tomcat 7 or Tomcat 8 versions. For more information
about downloading and installing the Tomcat server, see http://tomcat.apache.org.
About this task

If you choose to install the application on a Tomcat server, you do not need to install it on WebLogic.
Procedure
1. Locate the Oracle JDBC jar files, ojdbc6.jar and xdb6.jar in the applicationname
\current\lib directory. Where applicationname is the name of the API application,
IntegrationApi or StudentApi. The same jar files are provided for both IntegrationApi and
StudentApi.
Later in the Tomcat configuration process, you will copy the Oracle JDBC jar file into the \lib
folder under the Tomcat installation directory.
The account that runs the Tomcat application server must configure environment settings to
support the application.
2. On a Linux system, ensure that CATALINA_HOME is defined to reference your Tomcat software
installation location.
Note: This step must be executed on a Linux system only, do not perform this step on the
Windows platform.
For example, in the CATALINA_HOME=/opt/apache-tomcat- 8.0.xx, xx indicates the

point version of Tomcat you have installed.
3. Define CATALINA_OPTS to configure the following JVM settings: CATALINA_OPTS="-server
-Xms2048m -Xmx4g -XX:MaxPermSize=512m"

Note: If you are deploying multiple Banner 9.x applications to the same Tomcat server, -Xmx
must be increased by 2g and -XX:MaxPermSize must be increased by 128m. You should
deploy Banner 9.x administrative applications to one Tomcat server instance and Banner 9.x
self-service applications to a separate Tomcat server instance.
You can define this variable in the account's profile startup script or you can add this definition in
$CATALINA_HOME/bin/catalina.sh for Linux or catalina.bat for Windows.
4. Optional: If you install Tomcat as a Windows service, few JVM arguments must be specified.
a) From the Windows Start menu, select Configure Tomcat application.
b) Select the Java tab.
c) In the Java Options field, add -XX:MaxPermSize=512m.
d) Set the initial memory pool to 2048.
e) Set the maximum memory pool to 4096.
f) Save the settings.
g) Restart the Tomcat Windows service.
5. Optional: To set up the Tomcat Server to enable remote Java Management Extensions (JMX)
connections, perform the steps in the Configure Java Management Extensions section. This is
useful for debugging and logging.
6. Define the JNDI datasource resource name for the application.
a) Edit $CATALINA_HOME/conf/context.xml.
b) Uncomment <Manager pathname="" /> to disable Tomcat session persistence.
For example: change the following:


to

<Manager pathname="" />
c) Add the ResourceLink definitions inside the <Context> element.
<ResourceLink global="jdbc/bannerDataSource"
name="jdbc/bannerDataSource"
type="javax.sql.DataSource"/>
<ResourceLink global="jdbc/bannerSsbDataSource"
name="jdbc/bannerSsbDataSource"
type="javax.sql.DataSource"/>
d) Save your changes in context.xml.

e) Edit $CATALINA_HOME/conf/server.xml to configure the database JNDI resource

name and connection pool configuration.
f) Add the Resource definitions inside the <GlobalNamingResources> element.
For Tomcat 7
<Resource name="jdbc/bannerDataSource" auth="Container"

type="javax.sql.DataSource"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@//hostname:port/service_name"
username="banproxy" password="the_banproxy_password"
initialSize="5" maxActive="100" maxIdle="-1"
maxWait="30000"
validationQuery="select 1 from dual"
testOnBorrow="true"/>
<Resource name="jdbc/bannerSsbDataSource" auth="Container"
username="ban_ss_user" password="ban_ss_user_pasword"
initialSize="5" maxActive="100" maxIdle="-1"
maxWait="30000"
For Tomcat 8
<Resource name="jdbc/bannerDataSource" auth="Container"

username="banproxy" password="the_banproxy_password"
initialSize="5" maxTotal="100" maxIdle="-1"
maxWaitMillis="30000"
accessToUnderlyingConnectionAllowed="true"
<Resource name="jdbc/bannerSsbDataSource" auth="Container"
username="ban_ss_user" password="ban_ss_user_pasword"
initialSize="5" maxTotal="100" maxIdle="-1"
maxWaitMillis="30000"
accessToUnderlyingConnectionAllowed="true"
For example: if your database server's name is myserver.university.edu

and the Oracle TNS Listener is accepting connections on port 1521 and your
database service's name is SEED, then the URL is jdbc:oracle:thin:@//
myserver.university.edu:1521/SEED.
g) Save your changes in server.xml.

h) Copy the Oracle JDBC jar file (ojdbc6.jar and xdb6.jar) from the
applicationname/current/lib directory to the $CATALINA_HOME/lib directory.
StudentApi. Choose only one API application from which to copy the .jar file.
i) Copy xdb6.jar from the applicationname/current/lib directory to the
$CATALINA_HOME/lib directory. Where applicationname is the name of the API
application, IntegrationApi or StudentApi. Choose only one API application from
which to copy the .jar file.
This step is not required for Tomcat 8.
j) Start the application server, $CATALINA_HOME/bin/startup to validate the configuration
of the Tomcat server.
For example: for Linux,
cd $CATALINA_HOME
$ bin/startup.sh
For Windows,
cd %CATALINA_HOME%
> bin\startup.bat
k) Browse http://servername:<port>.
Set system properties on Tomcat
To override the configuration that was added into the WAR file, you must set system properties
to point to external configuration files. Add the specific property for each application that you are
installing, Integration API and Student API.
export JAVA_OPTS=
"-DBANNER_APP_CONFIG=<full file path to banner_configuration.groovy>
-DBANNER_INTEGRATION_API_CONFIG=<full file path to

IntegrationApi_configuration.groovy>"
-DBANNER_STUDENT_API_CONFIG=<full file path to

StudentApi_configuration.groovy>"
Customers upgrading from a release before 9.9 should note that the property for IntegrationApi has
changed from
-DBANNER_FINANCE_API_CONFIG=
to
-DBANNER_INTEGRATION_API_CONFIG=
You will need to make this change when setting system properties.

Configure Java management extensions
This is an optional step that enables you to monitor or debug the application.
About this task

Java Management Extensions (JMX) is a Java technology that supplies tools for managing and
monitoring applications, system objects, devices, and service oriented networks. Enabling JMX
connections allows you to remotely monitor and debug the application server.
Procedure
1. Add the following options to the catalina.sh or catalina.bat file and restart the Tomcat
server.
set CATALINA_OPTS=-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8999
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=your.hostname.com
2. Change the java.rmi.server.hostname value to the hostname or IP address of the

machine where Tomcat is installed.
For example:
-Djava.rmi.server.hostname=prod.appserver1.com
or
-Djava.rmi.server.hostname=149.24.3.178
3. JMX does not define a default port number to use. If necessary, change
com.sun.management.jmxremote.port to use port 8999.
Ellucian recommends that you connect remotely to the Tomcat server using JMX.
Warning! Ensure that the jmxremote.authenticate parameter is not set to False in a

production environment. If it is set to False, it does not require connections to be authenticated
and will create a security threat. For more information, see http://tomcat.apache.org/tomcat-6.0-
doc/monitoring.html#Enabling_JMX_Remote.
Configure the WebLogic server

To configure the web application and deploy the WAR file to the WebLogic server, you must perform
certain tasks such as verifying certain WebLogic prerequisites, creating a WebLogic machine, and
creating a WebLogic server.
If you choose to install the application on a WebLogic server, you need not install it on Tomcat.

Verify WebLogic prerequisites
Ensure that the WebLogic prerequisites are fulfilled before configuring your WebLogic server.
Procedure
1. Ensure that WebLogic is installed.

WebLogic can be downloaded and installed from the Oracle web site.
2. Ensure that the minimum requirement for OFM is 11.1.1.4+
3. Ensure that both the WebLogic node manager and the administration server are started.
The administration server can be accessed using the following URL, http://server:7001/
console.
Configure WebLogic
WebLogic releases include specific versions of the JDBC JAR files, but the versions used are those
that ship with the Banner application release.
About this task

For more information about JDBC JAR files, see the Oracle documentation.
Procedure
1. Copy the Oracle JAR files (ojdbc6.jar and xdb6.jar) from the $PRODUCT_HOME/
current/lib directory to the $MIDDLEWARE_HOME/modules directory.
• $PRODUCT_HOME is where the application's release zip file is unpacked and installed. The
same jar files are provided for both IntegrationApi and StudentApi.
• $MIDDLEWARE_HOME is the location where Oracle WebLogic is installed.
Note: This step is not required for Web Logic 12c (12.1.3).
2. For Linux or Unix servers, edit the setDomainEnv.sh file under the $MIDDLEWARE_HOME/
user_projects/domains/<CUSTOM_DOMAIN>/bin folder and update the ADD
EXTENSIONS comment with additional information.
For example:
#ADD EXTENSIONS TO CLASSPATH

export MIDDLEWARE_HOME="/u01/app/oracle/Middleware"
export WLS_MODULES="${MIDDLEWARE_HOME}/modules"
export EXT_PRE_CLASSPATH="${WLS_MODULES}/xdb6.jar"
if [ "${EXT_PRE_CLASSPATH}" != "" ] ; then
if [ "${PRE_CLASSPATH}" != "" ] ; then
PRE_CLASSPATH="${EXT_PRE_CLASSPATH}${CLASSPATHSEP}${PRE_CLASSPATH"}
export PRE_CLASSPATH
else
PRE_CLASSPATH="${EXT_PRE_CLASSPATH}"
export PRE_CLASSPATH

fi
fi
3. For MS Windows servers, edit the setDomainEnv.cmd under the $MIDDLEWARE_HOME/

user_projects/domains/<CUSTOM_DOMAIN>/bin folder and update the ADD
EXTENSIONS comment with additional information.
For example:
@REM ADD EXTENSIONS TO CLASSPATH

set MIDDLEWARE_HOME=D:\Oracle\Middleware
set WLS_MODULES=%MIDDLEWARE_HOME%\modules
set EXT_PRE_CLASSPATH=%EXT_PRE_CLASSPATH%;%WLS_MODULES%\xdb6.jar
if NOT "%EXT_PRE_CLASSPATH%"=="" (
if NOT "%PRE_CLASSPATH%"==" (
set PRE_CLASSPATH=%EXT_PRE_CLASSPATH%,%PRE_CLASSPATH%
) else (
set PRE_CLASSPATH=%EXT_PRE_CLASSPATH%
)
)
4. Restart the WebLogic Server.
Create a WebLogic machine
You need not create a WebLogic machine definition again if you have already created a machine
earlier.
Procedure
1. In the Change Center frame, click Lock & Edit.

2. In the Domain Structure frame, click (+) to expand and view the list of environments.
3. Click the Machines link.
4. Click New.
5. Enter a machine name and click Next.
6. Accept the defaults and click Finish.
7. In the Change Center frame, click Activate Changes.
Create a WebLogic Managed Server
If you previously created a WebLogic server for the application, you can use the same server and
skip this step.
Procedure

2. In the Domain Structure frame, click (+) to expand and view the list of environments.
3. Click the Servers link.

4. Click New.
5. Enter a server name and server listen port.
For example, the server name could be Banner9 and server listen port 8180.
6. Click Finish.
7. Click the newly created server link.
8. In the General tab, assign the machine to this server.
9. Click Save.
10. Select the Server Start tab.
11. Add the following to the Arguments text area: -server -Xms2048m -Xmx4g -
XX:MaxPermSize=512m.
Note: If you are deploying multiple Banner 9.x applications to the same WebLogic server,
increase -Xmx (max heap) by 2g and -XX:MaxPermSize by 128m. You should deploy Banner
9.x Administrative applications to one WebLogic server instance and Banner 9.x Self-Service
applications to a separate WebLogic server instance.
If you are using JRockit JVM, use the following parameters: -Xms2048m -Xmx4g
For JRockit, increase the max heap (-Xmx) by 2g for each Banner 9.x application that is
deployed.
12. Click Save.
14. In the Domain Structure frame, click the Servers link.
15. Select the Control tab.
16. Select the check box next to your new server definition.
17. Click Start.
Set system properties on Weblogic
To override the configuration that was added into the WAR file, you must set system properties
to point to external configuration files. Add the specific property for each application that you are
installing, Integration API and Student API.
Append the following to the arguments text area:
-DBANNER_INTEGRATION_API_CONFIG=<full file path to

IntegrationApi_configuration.groovy>"
-DBANNER_STUDENT_API_CONFIG=<full file path to

StudentApi_configuration.groovy>"
Customers upgrading from a release before 9.9 should note that the following section has changed
from
-DBANNER_FINANCE_API_CONFIG=

to
-DBANNER_INTEGRATION_API_CONFIG=
You will need to make this change when setting system properties.
Create an administrative datasource and connection pool
Configure an application's connection to the Oracle database for administrative users. If you have
already created an administrative datasource and connection pool, you need not create this again.
Procedure

2. In the Domain Structure frame, click (+) to expand Services and then select Data Sources.
3. Click New.
4. Select Generic DataSource.
5. Specify a datasource name.
For example, Banner9DS.
6. Specify the JNDI name.
For example: a JNDI name can be jdbc/bannerDataSource.
7. Specify Oracle for Database Type and then click Next.
8. Select Oracle Driver (Thin) for Service Connections and then click Next.
9. Clear the Supports Global Transactions check box and then click Next.
10. Enter the database name, host name, port, user name, password, and password confirmation,
and then click Next.
For example:
Database name BAN9

Host name yourhostname.yourdomain.com
Port 1521
UserName banproxy
Password your_password
11. Click Test Configuration.

12. Click Next for the connection test to be successful.
13. Select the server that you previously created to allow the datasource to be deployed and used
by this server.
14. Click Finish.
15. Select the datasource link that you created.
16. Select the Connection Pool tab.
a) Set the Initial Capacity parameter to specify the minimum number of database connections
to be created when the server starts up.

For example: Initial Capacity = 5

b) Set the Maximum Capacity parameter to specify the maximum number of database
connections that can be created.
For example: Maximum Capacity = 100
17. Change Statement Cache Type = Fixed.
18. Change Statement Cache Size = 0.
19. Click Save.
Create a Self-Service datasource and connection pool
Configure an application's connection to the Oracle database for self-service users. If you have
already created a self-service datasource and connection pool, you need not create this again.
Procedure

2. In the Domain Structure frame, click (+) to expand Services and then select Data Sources.
3. Click New.
4. Select Generic DataSource.
5. Specify a datasource name.
For example, Banner9SSbDS.
6. Specify the JNDI name.
A JNDI name can be jdbc/bannerSsbDataSource.
7. Specify Oracle for Database Type and then click Next.
8. Select Oracle Driver (Thin) for Service Connections and then click Next.
9. On the Transaction Options page, clear the Supports Global Transactions check box and
then click Next.
10. Enter the database name, host name, port, user name, password, and password confirmation,
and then click Next.
Database name BAN9

Host name yourhostname.yourdomain.com
Port 1521
UserName ban_ss_user
Password your_password
11. Click Test Configuration.

12. Click Next for the connection test to be successful.
13. Select the server that you previously created to allow the datasource to be deployed and used
by this server.

14. Click Finish.

15. Select the datasource link that you created.
16. Select the Connection Pool tab.
a) Set the Initial Capacity parameter to specify the minimum number of database connections
to be created when the server starts up.
Initial Capacity = 5
b) Set the Maximum Capacity parameter to specify the maximum number of database
connections that can be created.
Maximum Capacity = 100
17. Change Statement Cache Type = LRU.
18. Change Statement Cache Size = 20.
19. Click Save.

Deploy the WAR File
Deploy the WAR File

Deploy the WAR file on either the Tomcat or Web Logic server that has been configured for the
purpose.
Deploy the WAR file to the Tomcat server

The systool that is used to create the WAR file can also be used to deploy the WAR file to a
Tomcat container. You should deploy 9.x administrative applications and 9.x self-service applications
to separate Tomcat servers to increase performance.
About this task
Note: The systool does not provide the capability to undeploy or redeploy an application. If you
are redeploying the application, you must use the Tomcat Manager web application to undeploy the
existing application.
The target supports deploying the dist/WAR file using the Tomcat Manager web application.
Because environments vary significantly with respect to user privileges, clustering approach, web
container version, operating system, and more, the target may or may not be suitable for your use.
Note: You can also deploy the WAR file to the Tomcat server by copying the WAR file to the Tomcat
webapps/ directory.
To use the target, you must provide the following information:
• URL- This is the URL of the manager application in the Tomcat server. For example: http://
localhost:8080/manager.
• Username- This Tomcat server username must have privileges to deploy WAR files.
• Password- This is the password of the Tomcat server user.
Username/password combinations are configured in your Tomcat user database <TOMCAT_HOME>

\conf\tomcat-users.xml. For Tomcat 8.x, you must configure at least one username/
password combination with the manager role. For example: <user username="tomcat"
password="tomcat" (your password) roles="manager-gui, manager"/>.
Note: The roles in Tomcat server changed between point releases in version 8.x. Refer to the
Tomcat documentation specific to your release for information on enabling access to provide the
appropriate role to a user account for deployment.
Procedure
1. Navigate to the applicationname\current\installer directory. Where

applicationname is the name of the API application, IntegrationApi or StudentApi.
2. Deploy Tomcat.

Deploy the WAR File
Operating system Instruction

Unix $ bin/systool deploy-tomcat
Windows > bin\systool deploy-tomcat
3. Enter the URL, []: http://localhost:8080/manager for the Tomcat Manager.

This URL will be accessed to deploy the WAR file into the container.
4. Enter a valid Tomcat username to deploy the WAR file.
This user must have the manager-gui role.
For example: []: tomcat
5. Enter the Tomcat password for the user:
This password will not be persisted.
For example: []: password
Deploy the WAR file to the WebLogic server

The WebLogic server uses the deployed WAR file and implements the code in the WAR file by
starting the application.
Procedure
1. Change the name of the WAR file to remove the version number.
For example: Change
applicationname/current/dist/
applicationname-9.15.war

StudentApi.
To
applicationname/current/dist/
applicationname.war
2. Access the administration server at http://server:7001/console.

3. In the Domain Structure frame, select the Deployments link.
4. In the Change Center frame, select Lock and Edit.
5. Click Install.
6. Select the WAR file to be deployed and then click Next.
The file is located at applicationname/current/dist.

StudentApi.

Deploy the WAR File
7. Select Install this deployment as an application and then click Next.

8. Select the target server on which to deploy this application and then click Next.
9. Click Finish.
11. Select the deployed application and then click Start.
12. Select Servicing all request.

Setup user access
Setup user access

This section details the steps to setup user access and to define user privileges.
Verify the banproxy database account

The banproxy account is used for database connections for administrative applications.
The database upgrade process grants the BAN_DEFAULT_M role and grants the BAN_FINANCE_C
role to banproxy for Banner Integration API. If this role is revoked, the application will not start
successfully.
The database upgrade process grants the BAN_DEFAULT_M role to ban proxy for Banner Student
API.
Verify Oracle user accounts to connect through banproxy

All Internet Native Banner (INB) or Oracle user accounts must connect using the banproxy
privilege. Verify that Oracle user accounts can connect through banproxy.
Procedure
1. Access the Security Maintenance (GSASECR) page.

2. Enter a valid user name.
3. Click Alter.
4. Select the Authorize banproxy check box.
5. Click Save.
Define user privileges for API access

APIs must be submitted with an authorization header. The authorization header ID must use a valid
Oracle ID with proxy access to the banproxy user. The ID must also have privileges to the Banner
security objects.
About this task
Security for accessing Banner 9.x APIs is similar to security for accessing Banner 8.x administrative
forms. If the Oracle ID cannot access the Banner security object, the API does not run and returns
an empty response.

Setup user access
Note: For guidelines on security objects, refer to the API documentation on the Ellucian XE
Registry.
To define privileges for the administrative account that accesses Banner Ethos APIs, perform the
following steps:
Procedure
1. Define the user’s default role to be the Oracle CREATE_SESSION privilege or the
USR_DEFAULT_CONNECT Oracle role.
2. Grant the BAN_DEFAULT_M and BAN_FINANCE_C Oracle role to the user. This role does not
need to be the default role, because it is password protected.
3. Authorize banproxy access on the Security Maintenance (GSASECR) page or with the ALTER
USER username GRANT CONNECT THROUGH BANPROXY command.
4. Define access to the General Menu (GUAGMNU) Banner security object by using the Security
Maintenance (GSASECR) page.
Note: These are the minimum privileges for accessing Banner Ethos APIs.
Conversion scripts to update current indicators in curriculum

The information in this section applies only to Student API. The curriculum conversion scripts only
need to be run one time at each institution.
To determine if they have already been run at your institution, query the SOBCTRL table for the
following four fields. If any of these fields does not have a value of Y, run the corresponding script
as noted. If the SOBCTRL field equals Y, that script has already been run at your institution and
there is no need to run it again.
• SOBCTRL_CURRENT_RECR_CDE - Run susoplccd_recr.sql. (Recruiting)

• SOBCTRL_CURRENT_ADM_CDE - Run susoplccd_adm.sql. (Admissions)
• SOBCTRL_CURRENT_LEARNER_CDE - Run susoplccd_learner.sql. (Learner)
• SOBCTRL_CURRENT_OUTCOME_CDE - Run susoplccd_outcome.sql. (Outcome)
The only APIs that require these scripts to be run are the following Student APIs. If your institution
does not use any of these APIs, the scripts do not have to be run.
• admission-applications
• student-academic-period-profiles
• student-academic-programs
If you are using these APIs and the scripts have not been run on the database, the APIs issue an
alert message like the following: Curriculum current indicator conversion scripts
must be run before accessing admissionapplications
The scripts are located in the $BANNER_HOME/student/plus directory.

Setup user access
These scripts, especially susoplccd_learner.sql, require a significant amount of time to run

in a production database. It is recommended that no one be using the system when the scripts
are run. In order to ensure this, start the database in the Restricted mode. The user ID that is
used to run the scripts will need the Restricted Session system privilege for the duration. For more
information, refer to the Oracle Server Administrator’s Guide.
To limit a potential increase in tablespace size, it is also recommended that you disable
the BEP (Banner Event Publisher) event triggers BEP_TRG_SATURN_SORLCUR and
BEP_TRG_SATURN_SORLFOS before running these scripts. These triggers can be disabled from
under the Adminstration tab of the BEP application. After the conversion scripts have completed,
be sure to re-enable these triggers.
If you observe an increased database size after running these scripts, refer to the troubleshooting
information in the What to do if CDCADMIN schema increases in size and slows down processes
section of the Banner Event Publisher Handbook.

Test the installation
Test the installation

Test the installation to ensure that the WAR file was deployed as required.
Procedure
1. Install a REST client application.
REST client is a plugin for Firefox and Google Chrome browsers. For example, Advance REST
Client is provided for the Google Chrome browser.
2. In the URL field, enter the API URL:
http://<host>:<port>/applicationname/api/about

StudentApi.
3. Add a new header for Accept type.
4. Enter a value for Accept type. For example:
Accept = application/json
5. Click the GET option.
6. Click Send. The application prompts for user authentication.
7. Enter valid user credentials.
If the installation is successful, the following message is displayed:
Status: 200 OK
Response body looks similar to the following:
"applicationName": "applicationname",
"applicationVersion": "9.15"

StudentApi and applicationVersion is the version of the API application running at the
institution.

Upgrades
Upgrades
Use the checklists to complete the required steps to upgrade Banner Integration API and Banner
Student API.
Upgrade Banner Integration API

The following checklist is to upgrade Banner Integration API to release 9.15.
1. Refer to Upgrading from releases before 9.9 on page 58
• List of moved APIs on page 58

• Manual changes needed for IntegrationApi_configuration.groovy on page 59
• Referencing IntegrationApi_configuration.groovy using environment properties on page 59
• Required Ethos Integration Configuration Changes on page 60
– Modify Ellucian Ethos Integration configuration for Student and Integration API endpoints on
page 60
• ILP Requirements on page 60

– Unix on page 26
3. Undeploy the existing application on page 61
• Tomcat on page 61
– Undeploy the application using the Tomcat Manager web application on page 61
– Undeploy application manually on UNIX on page 61
– Undeploy application manually on Windows on page 62
• Undeploy the application using WebLogic on page 62


Upgrades

Upgrade Banner Student API

The following checklist is to upgrade Banner Integration API to release 9.15.
1. Refer to Upgrading from releases before 9.9 on page 58
• List of moved APIs on page 58

• Required Ethos Integration Configuration Changes on page 60
– Modify Ellucian Ethos Integration configuration for Student and Integration API endpoints on
page 60

– Unix on page 26
3. Undeploy the existing application on page 61
• Tomcat on page 61
– Undeploy the application using the Tomcat Manager web application on page 61
– Undeploy application manually on UNIX on page 61
– Undeploy application manually on Windows on page 62
• Undeploy the application using WebLogic on page 62


Upgrades


Upgrading from releases before 9.9

Before the 9.9 release, clients installed the Integration API if they had Finance or Payroll, and
installed the Student API if they had Student (which includes Financial Aid).
Starting with the 9.9 release, all clients must now install the Integration API even if they do not have
Finance or Payroll. The Integration API is now the foundational API that contains all the APIs that
are not related to Banner Student. There are additional configuration changes that you must apply in
order for the APIs to operate as expected.
List of moved APIs

The following API resources have been moved from the Student API to the Integration API.
• address-types
• addresses
• buildings
• citizenship-statuses
• comment-subject-area
• comments
• educational-institutions
• email-types
• ethnicities
• geographic-area-types
• geographic-areas
• marital-statuses
• organizations
• person-filters
• person-name-types
• person-visas
• persons
• persons-credentials
• phone-types
• races
• religions
• restriction-types
• room-characteristics
• room-types

• rooms
• sites
• sources
• visa-types
To access API resources, you must configure Ethos Integration with a new URL using /
IntegrationApi as the context path instead of /StudentApi.
Manual changes needed for

IntegrationApi_configuration.groovy
This section applies only to the Integration API. When installing a new release of
any XE application, your existing application configuration file is preserved. With
the Integration API now being required for all clients from the 9.9 release, the
IntegrationApi_configuration.groovy has been modified to replace references of
‘Finance’ with ‘Integration’ in the log4j configuration and log file name as shown.
jmx {
exported {
log4j = "IntegrationApi-log4j"
}
}
log4j = {
String loggingFileDir = (System.getProperty('catalina.base') ?:
'target')
String logAppName = "IntegrationApi"

String loggingFileName = "${loggingFileDir}/logs/
${logAppName}.log".toString()
You will be instructed to make this change when installing the Integration API application.
Referencing IntegrationApi_configuration.groovy using

environment properties
This section applies only to the Integration API. For Tomcat, you can use an environment property to
point to the location of the IntegrationApi_configuration file on your file system.
The name of that property is has been renamed from the 9.9 release onwards from
BANNER_FINANCE_API_CONFIG to BANNER_INTEGRATION_API_CONFIG.
The same modification applies to Weblogic using either an environment property or through Server
Start parameters if you start your application through the Weblogic console.

Required Ethos Integration Configuration Changes

In order for Ethos Integration to correctly route the any API request to the new post-9.9
configuration, you must change any existing resource maps you may have setup previously.
Modify Ellucian Ethos Integration configuration for Student and

Integration API endpoints
Modify the Ellucian Ethos Integration configuration based on what you currently have deployed.
Procedure
1. If you only have Integration API currently deployed and that is all you need, simply add the
resources referenced in the List of moved APIs section to the Integration API list of resources
owned.
2. If you only have Student API currently deployed, you need to create a new Ellucian Ethos API
application record for IntegrationApi, which all clients must now install. Remove the moved
resources from StudentApi and add them to the new IntegrationApi.
3. If you have both Student API and Integration API currently deployed, remove the moved
resources from the StudentApi application record and add them to the IntegrationApi application
record.
What to do next
Ensure that you correctly configure the Ellucian Messaging Adapter (EMA). Refer to the Configure
the Message Adapter resource on the Ellucian Ethos Resources site (resources.elluciancloud.com)
for configuration guidance for multiple API deployments. This can be found in the Integration
Resources section in the Ethos Integration Administrative Guide.
ILP Requirements
If your institution uses the Intelligent Learning Platform (ILP), upgrading Banner Integration API
requires that you also upgrade your ILP version and enter settings in the ILP Console.
If you have an on-premises installation of ILP, do the following using the procedures in the ILP 4.5.1
Release Guide:
• Upgrade to ILP 4.5.1 or later.

• Enter the Banner Integration API URL and credentials in the ILP Console.
If you have a software-as-a-service (SaaS) implementation of ILP, you will need to enter the Banner
Integration API URL and credentials in the ILP Console. For the procedure, see the ILP 4.5.1
Release Guide.

Undeploy the existing application

Before you install Banner Ethos 9.15, you must undeploy the previous version.
The procedure for undeploying the applications varies depending on whether you are using Tomcat
or WebLogic servers.
Tomcat
You can either use the Tomcat Manager web application to undeploy Banner Student API, or you
can shut down Tomcat and manually remove the files.
Undeploy the application using the Tomcat Manager web application
Undeploy the previously deployed version of the application from the Tomcat server using the
Tomcat Manager web application.
Procedure
1. Access the Tomcat Manager web application at one of the following URLs: http://
server:8080/manager or http://server:8080/manager/html.
2. Access the deployment page using a valid user name and password.
3. Click Stop in the Commands area to stop the existing application.
4. In the confirmation dialog box, click OK.
5. In the Commands area, click Undeploy.
6. In the confirmation dialog box, click OK to undeploy the application.
Undeploy application manually on UNIX
Shut down Tomcat and manually undeploy any previously deployed versions of the application on
your UNIX systems.
Procedure
1. Log in to the server on which Tomcat is running by using the credentials that were used to start
Tomcat.
2. Shut down Tomcat by running the following shutdown script: $CATALINA_HOME/bin/
shutdown.sh.
3. Remove the current deployment with this command:
cd $CATALINA_HOME

rm -rf $CATALINA_HOME/webapps/<xxx>
Insert the name of the application you want to remove for xxx. For example:
cd $CATALINA_HOME
rm -rf $CATALINA_HOME/webapps/banner9applicationname
4. Remove the associated WAR file for each of the applications removed in the previous step: rm
-rf $CATALINA_HOME/webapps/war_file_name.
Undeploy application manually on Windows
Shut down Tomcat and manually undeploy any previously deployed versions of the application on
your Windows systems.
Procedure
1. Shut down Tomcat.
If you have Then

Installed Tomcat as a service Use the Service Control panel to stop the
application.
Not installed Tomcat as a service Use the following shutdown script:
%CATALINA_HOME%\bin\shutdown.bat
2. Stop the previously deployed version of this application.

3. Remove the previously deployed version by using this command.
rmdir %CATALINA_HOME%\webapps\<xxx> /s/q
Insert the name of the application you want to remove for xxx. For example:
rmdir %CATALINA_HOME%\webapps\banner9applicationname /s/q
4. Remove the associated WAR file for each of the applications removed in the previous step: del
%CATALINA_HOME%\webapps\war_file_name /q.
Undeploy the application using WebLogic

Undeploy the previously deployed version of the application using WebLogic.
Procedure
1. Access the administration server using the following URL: http://server:7001/console.

2. In the Domain Structure frame, click Deployments.

3. In the Change Center, click Lock and Edit.

4. Select the check box for the version of the application that you want to undeploy, and click Stop.
5. Click Force Stop Now.
6. In the Force Stop Application Assistant page, click Yes.
7. Select the check box of the application that you stopped in the previous step.
8. Click Delete.
9. In the Delete Application Assistant page, click Yes.

WebLogic Troubleshooting
If Banner Ethos API is deployed on a WebLogic server, use this chapter to troubleshoot the
WebLogic configuration for Java Persistence API (JPA).
Disable WebLogic basic authentication

If you receive a prompt for authentication from a WebLogic realm rather than the Banner REST API
realm, use the following procedure to disable WebLogic's default basic authentication security for
the domain.
About this task
Procedure
1. Navigate to the config directory where WebLogic is configured. For example:
cd /MIDDLEWARE_HOME/user_projects/domains/base_domain/config
where MIDDLEWARE_HOME is /u01/app/oracle/middleware.

2. Open config.xml in a text editor.
3. Add the tag <enforce-valid-basic-auth-credentials>false</enforce-valid-
basic-auth-credentials> to config.xml as follows:
• For WebLogic 10.3.5, add the tag before the <cross-domain-security-

enabled>false</cross-domain-security-enabled> tag.
• For other WebLogic servers, add the tag before the closing </security-
configuration> tag.
4. Save the file.
5. Restart the WebLogic server.
Change the WebLogic configuration for JPA 2.0

If the following error message is displayed after you start the application, you must change the
WebLogic configuration for Java Persistence Architecture (JPA) 2.0.
ERROR context.GrailsContextLoader - Error initializing the application: Error creating bean

with name 'transactionManagerPostProcessor': Initialization of bean failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'trans
actionManager': Cannot resolve reference to bean 'sessionFactory' while setting bean property
'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'sessionFactory': Invocation of init method failed; nested
exception is java.lang.NoSuchMethodError: javax.persistence.OneToOne.orphanRemoval()Z

org.springframework.beans.factory.BeanCreationException: Error creating bean

with name 'transactionManagerPostProcessor': Initialization of bean failed; nested
exception is org.springframework.b eans.factory.BeanCreationException: Error
creating bean with name 'transactionManage! r': Cannot resolve reference to bean
'sessionFactory' while setting bean property 'sessionFactory'; nested exc eption is
org.springframework.beans.factory.BeanCreationException: Error creating bean with name
'sessionFactory': Invocation of init method failed; nested exception is java.lang.NoSuchMethodErr
or: javax.persistence.OneToOne.orphanRemoval
To correct the error, you must run the Oracle Weblogic patch to enable JPA 2.0 in Weblogic 10.3.6.
Note: For more information on JPA 2.0 support, see http://docs.oracle.com/cd/E17904_01/

web.1111/e13720/using_toplink.htm#EJBAD1309.
HTTP response code 500 and errors related to PL/SQL in API

log
This is to help troubleshoot Student API response code 500 and PL/SQL errors if seen in the API
log messages.
About this task
If the Student API was recently upgraded, ensure the environment meets following checklist:
Procedure
1. Ensure all the permissions are set correctly for the API user to be able to execute these objects.
For example, check for appropriate public synonyms, grants, etc.
Refer to FAQ CMS-12154 - How do I create public synonyms for all Banner objects?
2. Execute guraltr.sql to find all db procedures that need to be compiled.
3. Execute gurutlrp.sql to ensure all db objects are valid.
4. Validate dba objects using below query:
select * from dba_objects where status = 'INVALID' order by owner,

object_name, object_type;
Expected: No records should be displayed

5. Check for Banner packages, functions, or procedures that may be owned by more than one
owner:
SELECT owner, object_name, object_type

FROM dba_objects c
WHERE c.object_name IN (SELECT object_name
FROM dba_objects a WHERE owner IN ('BANINST1', 'BANSECR', 'NLSUSER',
'WTAILOR')

AND object_TYPE IN ('PACKAGE','FUNCTION','PROCEDURE') AND (SELECT

COUNT (*)
FROM dba_objects b WHERE a.object_name = b.object_name
AND a.object_type = b.object_type) > 1)
AND c.object_TYPE IN ('PACKAGE','FUNCTION','PROCEDURE')
ORDER BY 2,1,3;
6. It is recommended that you re-deploy the .war file, delete the application server work directory
to clear the cache and restart the application server.

Appendix A - Ellucian Messaging Service Installation and Configuration
Appendix A - Ellucian Messaging Service

Installation and Configuration
To integrate Banner with third party systems, you must install the Ellucian Messaging Service.
The Ellucian Messaging Service is the messaging service that facilitates use of the Advanced
Message Queuing Protocol (AMQP) standard and associated AMQP components. The Ellucian
Messaging Service works as the intermediate system between Banner and Elevate.
The following details apply.
• You should install and configure the Ellucian Messaging Service components on the Banner
Event Publisher (BEP) server. The Messaging Service includes Erlang and RabbitMQ 3.3.4.
• You can install the components on either a Linux or Windows operating system, depending on
your institution's needs.
See the documentation in the Ethos Resources site https://resources.elluciancloud.com/ for

information about the messaging service and its components, versions, dependencies, and install
instructions.
Note: Site information is intended for use by the IT system administrator.

Appendix B - Elevate Support

Fine-Grained Access Control (FGAC) and Value-Based Security (VBS) are used to restrict access to
Elevate data to read only. Scripts and seed data are delivered for FGAC and VBS.
Before upgrading to this release of Ethos API, check the Ellucian Product Compatibility Matrix for
the versions of Elevate that are compatible with this release.
A course is considered to be an Elevate course when the integration partner value in the
SCRINTG_INTG_CDE field is ELEV8, or when the value in SCBCRSE_DATA_ORIGIN field is
Elevate.
A section is considered to be an Elevate course when the integration partner value in the
SSBSECT_INTG_CDE field is ELEV8
Forms restricted using FGAC

This section lists the forms that are restricted to use FGAC.
Courses
You can view Elevate courses on the following forms. You cannot perform any inserts, updates, or
deletions for Elevate courses.
• Basic Course Information (SCACRSE) form

• Course Detail Information (SCADETL) form
• Course Registration Restrictions (SCARRES) form
• Catalog Prerequisite and Test Score Restrictions (SCAPREQ) form
• Catalog Schedule Restrictions (SCASRES) form
• College and Department Text (SCATEXT) form
• Course Syllabus (SCASYLB) form
• Mutual Course Exclusion (SCAMEXC) form
Sections
You can view Elevate sections on the following forms. You cannot perform any inserts, updates, or
deletions for Elevate sections.
• Faculty Assignment (SIAASGN) form

• Schedule (SSASECT) form

• Schedule Detail (SSADETL) form

• Schedule Restrictions (SSARRES) form
• Schedule Prerequisite and Test Score Restrictions (SSAPREQ) form
• Section Comment (SSATEXT) form
• Section Web Controls (SSAWSEC) form
• Schedule Evaluation (SSAEVAL) form
• Schedule Override (SSAOVRR) form
• Schedule Calendar (SSAACCL) form
• Schedule Processing Rules (SSARULE) form
• Section Syllabus (SSASYLB) form
New packages
The following packages have been added for integration.
SIKWKLD0/SIKWKLD1
This package is used to calculate the workload of a faculty member using their contract information.
Elevate and Banner FGAC and VBS

Banner users are prevented from modifying Course Catalog and Class Schedule data that
originates from the Elevate system. The Oracle ID that executes the API to post catalog course
and schedule section entries from Elevate must still be able to insert, update, and delete data.
Therefore, FGAC with VBS is used to control access to the data. Seed data and scripts are
delivered to run the required processes, including defining the FGAC rule and predicates and
enabling policies.
For more information on using FGAC with VBS, refer to the Banner General Data Security
Handbook and the “Student System Management” chapter of the Banner Student User Guide.
Guidelines for Oracle user that submits API
The Oracle user should be able to log in to SQL*Plus but should not have any object level privileges
to specific Banner tables. The Oracle user that is created and used in the authorization header of
the API that posts catalog and schedule entries to Banner must have the following attributes.
• Authorize proxy access to BANPROXY. On the GSASECR page for the User ID, make sure the
Authorize BANPROXY check box is selected.
• The CONNECT and BAN_DEFAULT_M roles need to be the default roles for the user.
• Access to security class for the BAN_ELEVATE_API_C Elevate API. This API includes objects
for each individual API such as PERSONS, API_COURSES, etc.

Update scripts
Scripts and seed data are delivered to control access to Course Catalog and Class Schedule.
Scripts are used to set up and populate the Business Profile and the FGAC and VBS rules,
predicates, and restrictions. Users are listed in a Banner business profile, and the business profile is
restricted on the FGAC predicate.
The following is a list of scripts, in the order in which they must be run. A description of each script
follows.
1. sgtvintpi_080700.sql
2. sgorintgi_080700.sql
3. sgtvfdmni_080700.sql
4. sgobfdmni_080700.sql
5. sgorfdpli_080700.sql
6. sgtvfgaci_080700.sql
7. sgtvfbpri_080700.sql
8. sgobfgaci_080700.sql
9. sgorfbpri_080700.sql
10. sgorfprdi_080700.sql
11. sgorfgbpi_080700.sql
12. sgorfdplu_080700.sql
13. sgorfbpri_sync_job.sql
sgtvintpi_080700.sql
This script is delivered as part of the DML directory and is used to create a record in the GTVINTP
table for the integration partner code. The data is displayed on the Integration Partner System Code
Validation (GTVINTP) form.
Integration Partner System Description

ELEV8 Elevate Partner
sgorintgi_080700.sql
This script is delivered as part of the DML directory and is used to create a record in the GORINTG
table for the integration partner code. The data is displayed on the Integration System Partner Rules
(GORINTG) form.
Integration Partner Description Cross Referenced Description

System Partner System
ELEV8 Elevate ELEV8 Elevate Partner

sgtvfdmni_080700.sql
This script is delivered as part of the DML directory and is used to insert new VBS domains for
the Course Catalog module in the GTVFDMN table. This data is displayed on the FGAC Domain
Validation (GTVFDMN) form.
VBS Domain Code Description Additional Information

SB_CATALOG_ELEVATE_VBS Student Catalog Elevate VBS Used for policy driven by the
Security SCBCRKY table on all Catalog
tables except SCRINTG
SB_SCRINTG_ELEVATE_VBS Student Catalog Elevate VBS Used for policy driven by the
Security SCBCRKY table only on the
SCRINTG table
sgobfdmni_080700.sql
This script is delivered as part of the DML directory and is used to insert the SCBCRKY driver table
for the two new VBS domains into the GOBFDMN table.
Domain Code Table Name Domain Type Sys Req Enable

Predicate PII
Code
SB_CATALOG_ELEVATE_VBS SCBCRKY VBS Y N
SB_SCRINTG_ELEVATE_VBS SCBCRKY VBS Y N
sgorfdpli_080700.sql
This script is delivered as part of the DML directory and is used to insert table definitions
for the Course Catalog tables defined for the SB_CATALOG_ELEVATE_VBS and
SB_CATALOG_ELEVATE_VBS domains into the GORFDPL table.
Domain Code Table Sys Req Active Ind Driver SQL

Name
SB_SCRINTG_ SCRINTG Y Y ' EXISTS (SELECT ''X''
FROM SCBCRKY WHERE
ELEVATE_VBS SCBCRKY_CRSE_NUMB =
SCRINTG_CRSE_NUMB
AND SCBCRKY_SUBJ_CODE =
SCRINTG_SUBJ_CODE '
from dual where not exists

( select 1 from gorfdpl
where gorfdpl_fdmn_code =
'SB_SCRINTG_ELEVATE_VBS'
and gorfdpl_table_name =
'SCRINTG');


Name
SB_SCRINTG_ SCBCRKY Y Y from dual where not exists
ELEVATE_VBS where gorfdpl_fdmn_code =
'SB_SCRINTG_ELEVATE_VBS'
'SCBCRKY');
SB_CATALOG_ SCRINTG Y Y ' EXISTS (SELECT ''X''
ELEVATE_VBS FROM SCBCRKY WHERE
SCBCRKY_CRSE_NUMB =
SCRINTG_CRSE_NUMB
SCRINTG_SUBJ_CODE '

'SB_CATALOG_ELEVATE_VBS'
'SCRINTG');
SB_CATALOG_ SCBCRKY Y Y from dual where not exists

ELEVATE_VBS ( select 1 from gorfdpl
'SCBCRKY');
SB_CATALOG_ SCBCRSE Y Y ' EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCBCRSE_CRSE_NUMB
SCBCRSE_SUBJ_CODE '

'SCBCRSE');


Name
SB_CATALOG_ SCBDESC Y Y ' EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCBDESC_CRSE_NUMB
SCBDESC_SUBJ_CODE '

'SCBDESC');
SB_CATALOG_ SCBSUPP Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCBSUPP_CRSE_NUMB
SCBSUPP_SUBJ_CODE '

'SCBSUPP');
SB_CATALOG_ SCRATTR Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRATTR_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRATTR_SUBJ_CODE '

'SCRATTR');


Name
SB_CATALOG_ SCRCLBD Y Y ' EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCRCLBD_CRSE_NUMB
SCRCLBD_SUBJ_CODE '

'SCRCLBD');
SB_CATALOG_ SCRCORQ Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRCORQ_CRSE_NUMB
SCRCORQ_SUBJ_CODE '

'SCRCORQ');
SB_CATALOG_ SCRCPRT Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRCPRT_CRSE_NUMB
SCRCPRT_SUBJ_CODE '

'SCRCPRT');


Name
SB_CATALOG_ SCRCRDF Y Y ' EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCRCRDF_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRCRDF_SUBJ_CODE '

'SCRCRDF');
SB_CATALOG_ SCREQIV Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCREQIV_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCREQIV_SUBJ_CODE '

'SCREQIV');
SB_CATALOG_ SCRFEES Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRFEES_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRFEES_SUBJ_CODE '

'SCRFEES');


Name
SB_CATALOG_ SCRGMOD Y Y ' EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCRGMOD_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRGMOD_SUBJ_CODE '

'SCRGMOD');
SB_CATALOG_ SCRLEVL Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRLEVL_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRLEVL_SUBJ_CODE '

'SCRLEVL');
SB_CATALOG_ SCRMEXC Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRMEXC_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRMEXC_SUBJ_CODE '

'SCRMEXC');


Name
SB_CATALOG_ SCRRARE Y Y ' EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCRRARE_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRARE_SUBJ_CODE '

'SCRRARE');
SB_CATALOG_ SCRRATT Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRRATT_CRSE_NUMB
SCRRATT_SUBJ_CODE '

'SCRRATT');
SB_CATALOG_ SCRRCAM Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRRCAM_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRCAM_SUBJ_CODE '

'SCRRCAM');


Name
SB_CATALOG_ SCRRCHR Y Y ’ EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCRRCHR_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRCHR_SUBJ_CODE '

'SCRRCHR');
SB_CATALOG_ SCRRCLS Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRRCLS_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRCLS_SUBJ_CODE '

'SCRRCLS');
SB_CATALOG_ SCRRCMP Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRRCMP_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRCMP_SUBJ_CODE '

'SCRRCMP');


Name
SB_CATALOG_ SCRRCOL Y Y ' EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCRRCOL_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRCOL_SUBJ_CODE '

'SCRRCOL');
SB_CATALOG_ SCRRDEG Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRRDEG_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRDEG_SUBJ_CODE '

'SCRRDEG');
SB_CATALOG_ SCRRDEP Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRRDEP_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRDEP_SUBJ_CODE '

'SCRRDEP');


Name
SB_CATALOG_ SCRRLVL Y Y ' EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCRRLVL_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRLVL_SUBJ_CODE '

'SCRRLVL');
SB_CATALOG_ SCRRMAJ Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRRMAJ_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRMAJ_SUBJ_CODE '

'SCRRMAJ');
SB_CATALOG_ SCRRPRG Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRRPRG_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRPRG_SUBJ_CODE '

'SCRRPRG');


Name
SB_CATALOG_ SCRRTRM Y Y ' EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCRRTRM_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRTRM_SUBJ_CODE '

'SCRRTRM');
SB_CATALOG_ SCRRTST Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRRTST_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRRTST_SUBJ_CODE '

'SCRRTST');
SB_CATALOG_ SCRSBGI Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRSBGI_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRSBGI_SUBJ_CODE '

'SCRSBGI');


Name
SB_CATALOG_ SCRSCHD Y Y ' EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCRSCHD_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRSCHD_SUBJ_CODE '

'SCRSCHD');
SB_CATALOG_ SCRSYLN Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRSYLN_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRSYLN_SUBJ_CODE '

'SCRSYLN');
SB_CATALOG_ SCRSYLO Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRSYLO_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRSYLO_SUBJ_CODE '

'SCRSYLO');


Name
SB_CATALOG_ SCRSYRM Y Y ' EXISTS (SELECT ''X''
SCBCRKY_CRSE_NUMB =
SCRSYRM_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRSYRM_SUBJ_CODE '

'SCRSYRM');
SB_CATALOG_ SCRSYTR Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRSYTR_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRSYTR_SUBJ_CODE '

'SCRSYTR');
SB_CATALOG_ SCRTEXT Y Y ' EXISTS (SELECT ''X''

SCBCRKY_CRSE_NUMB =
SCRTEXT_CRSE_NUMB AND
SCBCRKY_SUBJ_CODE =
SCRTEXT_SUBJ_CODE '

'SCRTEXT');


Name
SB_SCHEDULE_ SIRASGN Y Y ' EXISTS (SELECT ''X''
VBS FROM SSBSECT WHERE
SSBSECT_CRN = SIRASGN_CRN
AND SSBSECT_TERM_CODE =
SIRASGN_TERM_CODE'
FROM dual WHERE NOT EXISTS
(SELECT 1 FROM gorfdpl
WHERE GORFDPL_FDMN_CODE
='SB_SCHEDULE_VBS' AND
GORFDPL_TABLE_NAME='SIRASGN');
SB_SCHEDULE_ SSRRATT Y Y ' EXISTS (SELECT ''X''

SSBSECT_CRN = SSRRATT_CRN
SSRRATT_TERM_CODE'
GORFDPL_TABLE_NAME='SSRRATT');
SB_SCHEDULE_ SSBWLSC Y Y ' EXISTS (SELECT ''X''

SSBSECT_CRN = SSBWLSC_CRN
SSBWLSC_TERM_CODE'
GORFDPL_TABLE_NAME='SSBWLSC');
SB_SCHEDULE_ SSRCLBD Y Y ' EXISTS (SELECT ''X''

SSBSECT_CRN = SSRCLBD_CRN
SSRCLBD_TERM_CODE'
GORFDPL_TABLE_NAME='SSRCLBD');


Name
SB_SCHEDULE_ SSRRCHR Y Y ' EXISTS (SELECT ''X''
SSBSECT_CRN = SSRRCHR_CRN
SSRRCHR_TERM_CODE'
GORFDPL_TABLE_NAME='SSRRCHR');
SB_SCHEDULE_ SSRRDEP Y Y ' EXISTS (SELECT ''X''

SSBSECT_CRN = SSRRDEP_CRN
SSRRDEP_TERM_CODE'
GORFDPL_TABLE_NAME='SSRRDEP');
sgtvfgaci_080700.sql
This script is delivered as part of the DML directory and is used to insert the VBS rule code used
to identify the Elevate rules into the GTVFGAC table. This data is displayed on the FGAC Group
Validation (GTVFGAC) form.
FCAC Code Description

ELEVATE Elevate Restrictions
sgtvfbpri_080700.sql
This script is delivered as part of the DML directory and is used to create the business profile code
in the GTVFBPR table. The data is displayed on the FGAC Business Profile Validation (GTVFBPR)
form.
FGAC Business Profile Code Description

ELEVATE Restrict Users from Elevate Data

sgobfgaci_080700.sql
This script is delivered as part of the DML directory and is used to insert the header record into the
GOBFGAC table. The header record stores the Active indicator setting and the Effective Date
value. The data is displayed on the FGAC Group Rules (GOAFGAC) form for the Group value in
the Key Block.
FGAC Code Active Indicator Effective Date

ELEVATE Y SYSDATE
sgorfbpri_0080700.sql
This script is delivered as part of the DML directory and is used to populate the business profile with
users in the GORFBPR table. The data is displayed on the FGAC Business Profile Assignments
(GOAFBPR) form for the FGAC Business Profile Code value and the associated Fine-Grained
Access User ID values.
FGAC User ID Business Profile Code

a.username ELEVATE
sgorfprdi_080700.sql
This script is delivered as part of the DML directory and is used to create the predicates. The
predicates state that the user assigned to the rule can insert, update, and delete data, when the
selects are true.
Entries are created for catalog (SB_CATALOG_ELEVATE_VBS), (SB_SCRINTG_ELEVATE_VBS),

and schedule (SB_SCHEDULE_VBS) in the GORFPRD table where the GORFPRD_FGAC_CODE
is ELEVATE. (Entries use the VBS domains that are part of the existing baseline seed data.)
The data is displayed on the FGAC Group Rules (GOAFGAC) form.

FGAC Code Domain Code Sys Num Predicate

ELEVATE SB_SCHEDLE_VBS 1 select 'ELEVATE',
'SB_SCHEDULE_VBS',
1,
sysdate,
user,
'nvl(SSBSECT_INTG_CDE,''x'') !
= ''ELEV8'''
from dual where not

exists ( select 1
from gorfprd where
gorfprd_fgac_code
= 'ELEVATE' and
gorfprd_fdmn_code =
'SB_SCHEDULE_VBS');
ELEVATE SB_CATALOG_VBS 2 select 'ELEVATE',
'SB_CATALOG_ELEVATE_VBS',
2,
sysdate,
user,
' not exists ( select 1

from scrintg vbs where
vbs.scrintg_subj_code =
scbcrky_subj_code
and vbs.scrintg_crse_numb
= scbcrky_crse_numb
and vbs.scrintg_intg_cde
= ''ELEV8'' )'
from dual where not

exists ( select 1
from gorfprd where
gorfprd_fgac_code
= 'ELEVATE' and
gorfprd_fdmn_code =
'SB_CATALOG_ELEVATE_VBS');

FGAC Code Domain Code Sys Num Predicate

ELEVATE SB_SCRINTG_VBS 3 select 'ELEVATE',
'SB_SCRINTG_ELEVATE_VBS',
3,
sysdate,
user,
' not exists ( select 1

from scbcrse vbs where
vbs.scbcrse_subj_code =
scbcrky_subj_code
and vbs.scbcrse_crse_numb
= scbcrky_crse_numb
and
upper(nvl(vbs.scbcrse_data_origin,''X''
= ''ELEVATE'' )'
from dual where not

exists ( select 1
from gorfprd where
gorfprd_fgac_code
= 'ELEVATE' and
gorfprd_fdmn_code =
'SB_SCRINTG_ELEVATE_VBS');
sgorfgbpi_080700.sql
This script is delivered as part of the DML directory and is used to insert access definition/
restrictions for the three domains on the Elevate VBS rule into the GORFGBP table. Access is
through the business profile. The ability to select, insert, update, and delete data is determined
by the predicate. The settings for the GORFGBP_SELECT_IND, GORFGBP_INSERT_IND,
GORFGBP_UPDATE_IND, and GORFGBP_DELETE_IND are displayed on the FGAC Group Rules
(GOAFGAC) form.
FGAC Domain Code Predicate FBPR Select Insert Ind Update Delete
Code Seq Num Code Ind Ind Ind
ELEVATE SB_ 1 ELEVATE N Y Y Y
SCHEDULE_
VBS
ELEVATE SB_CATALOG_ 2 ELEVATE N Y Y Y
ELEVATE_VBS

FGAC Domain Code Predicate FBPR Select Insert Ind Update Delete
Code Seq Num Code Ind Ind Ind
ELEVATE SB_ SCRINTG_ 3 ELEVATE N Y Y Y
ELEVATE_VBS
sgorfdplu_080700.sql
This script is delivered as part of the DML directory and is used to update the status on the domain
policy tables to “active” in the GORFDPL table.
Domain Name Table Name Active Ind

SB_CATALOG_ELEVATE_VBS All tables in GORFDPL Y
with domain
SB_CATALOG_ELEVATE_VBS
except SCRINTG
SB_SCHEDULE_VBS All tables in GORFDPL with Y
domain SB_SCHEDULE_VBS
SB_SCRINTG_ELEVATE_VBS SCRINTG Y
sgorfbpri_sync_job.sql
This script is delivered as part of the PLUS directory and is used to schedule a daily job (at 3:00
AM) to populate the business profile with new Oracle users in the GORFBPR table.
FGAC tips
When using FGAC, remember the following.
Variables for FGAC in Banner are managed within the Oracle session. If the predicate or restrictions
are changed, the user must log out of Banner and re-enter a new session to pick up any changes.
The scripts used to enable the policies should be run after regular business hours.

Create/activate FGAC policies
After running the Elevate FGAC seed data scripts, the gfvbsaddpol.sql script must be run to create
policies for Banner tables. The gfvbsaddpol.sql script is located in the Banner General PLUS
directory.
Use BANINST1 to run gfvbsaddpol.sql
You must use the BANINST1 User ID when you run the script to create the policies. The predicate
package owner must equal the policy owner. In this case, GOKFGAC is owned by BANINST1.
About this task
Procedure
1. From SQL*Plus, run the gfvbsaddpol.sql script while logged in with the BANINST1 User ID.
2. You are prompted for a table name. You can use wildcards (SS for Schedule tables, SC for
Catalog tables).
3. Provide the owner name for the table owner when prompted, for example SSBSECT is owned
by SATURN.
Results
This task is performed one time per module to create policies for SC% and SS% tables as identified
in the GORFDPL table. The script will create a policy for each table. This task does not need to be
repeated if the gorfdpl_driver.sql script changes, the table is added to another domain, or
there is any change to the domain and table.
Note: The gfvbsaddpol.sql script is can be rerun and restarted. The process will not try to
recreate a policy. If the policy exists, the task to add the policy is skipped.
Run gfvbsaddpol.sql.for the following tables:
SCBCRKY SCRRDEG
SCBCRSE SCRRDEP
SCBDESC SCRRLVL
SCBSUPP SCRRMAJ
SCRATTR SCRRPRG
SCRCLBD SCRRTRM
SCRCORQ SCRRTST
SCRCPRT SCRSBGI
SCRCRDF SCRSCHD
SCREQIV SCRSYLN

SCRFEES SCRSYLO
SCRGMOD SCRSYRM
SCRINTG SCRSYTR
SCRLEVL SCRTEXT
SCRMEXC SIRASGN
SCRRARE SSBWLSC
SCRRATT SSRCLBD
SCRRCAM SSRCLBD
SCRRCHR SSRRATT
SCRRCLS SSRRCHR
SCRRCMP SSRRDEP
SCRRCOL
View Policy Data from SQL*Plus
GORFDPL creates four policies per table, one each for the insert, update, delete and select items.
All have the package defined as GOKFGAC and must be owned by BANINST1.
Policy names
The gokfgac.f_get_policy_name function ensures that the policy name created is less than 30
characters in length.
If the table name length is less than 19 characters, the policy name will use the following pattern:
GOKFGAC_tablename_INS (INS, UPD, DEL, SEL)
If the table name length is 19 or more characters, the policy name will use the following pattern:
tablename_I (I, U, D, S)
Drop a policy
To drop a policy, run the gfgacdroppol.sql script from the Banner General PLUS directory using
the BANINST1 ID. This script accepts wildcards for the table name prompt.
Schedule a daily job to populate the business profile
A sgorfbpri_sync_job.sql script is delivered with this release and can be found in the PLUS
directory. It is run using the SATURN ID. It is used to schedule the synchronization process for the
user IDs that adds new Oracle users to the Elevate group business profile.
Automation of the synchronization process ensures that newly created users are not able to modify
any data related to Elevate courses and sections. The default synchronization is performed each

day at 3:00 AM. The default value can be changed according to your site-specific synchronization
interval requirements.

Banner Ethos API: Installation Guide

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Banner Ethos API: Installation Guide

Hochgeladen von

Copyright:

Verfügbare Formate

Banner Ethos API

Notices and Privacy

Ellucian's Privacy Statement is available at: www.ellucian.com/privacy.

Ellucian - Confidential and Proprietary 2

Perform the Ethos API DB Upgrade steps..................................................................... 13

Upgrade the application database..................................................................................... 25

Ellucian - Confidential and Proprietary 3

Customize the WAR file..........................................................................................................29

Regenerate the WAR file........................................................................................................ 36

Configure a Web Application Server................................................................................ 37

Deploy the WAR File................................................................................................................ 48

Setup user access.................................................................................................................... 51

Test the installation.................................................................................................................. 54

Upgrading from releases before 9.9..................................................................................58

Ellucian - Confidential and Proprietary 4

List of moved APIs......................................................................................................................58

Undeploy the existing application..................................................................................... 61

Appendix A - Ellucian Messaging Service Installation and Configuration........ 67

Appendix B - Elevate Support............................................................................................. 68

Ellucian - Confidential and Proprietary 5

Schedule a daily job to populate the business profile................................................... 91

Ellucian - Confidential and Proprietary 6

APIs Application to Install Mandatory DB Optional DB Modules

Ellucian - Confidential and Proprietary 7

Known installation issues

API knowledge article numbers

Recommended: Quad core CPU with 4 to 8 GB of memory for

The minimum supported version is Oracle Database Release 11.2.0.4.

The application is supported on the following application servers.

Ellucian - Confidential and Proprietary 8

• Apache Tomcat: 7 and 8.

Middle tier (application server) platforms

Tomcat (64 bit) WebLogic (64 bit)

• Ethos API DB Upgrade 9.15

– Banner Admin Common 9.3.16

Ellucian - Confidential and Proprietary 9

• (Optional) INTCOMP 8.0.2.6

Ellucian - Confidential and Proprietary 10

Open ports in the firewall

1. Open the firewall ports listed below.

Source Destination Port Purpose

Source Destination Port Purpose

5671 - Not secure

Ellucian - Confidential and Proprietary 11

Deployment of multiple web applications

F5 load balancer configuration

It was configured with the following settings:

Load Balancing type = Round Robin

Ellucian - Confidential and Proprietary 12

Perform the Ethos API DB Upgrade steps

Perform the Ethos API DB Upgrade steps

Recommendation for database partitioning

Ellucian - Confidential and Proprietary 13

GUID Generation Process

Identify GUID triggers

These triggers will be named in one of the following formats:

• <product code>T_<table_name>_GUID_TRG (the most common). For example,

Ellucian - Confidential and Proprietary 14

GUID triggers can be identified with the following SQL:

select owner, trigger_name, trigger_type, triggering_event, table_name

A GURTRCK record contains the following columns:

– GUID_GEN - GURGUID selects these records for GUID generation

– SERIAL - GUIDs will be generated for all records at once.