Академический Документы
Профессиональный Документы
Культура Документы
Installation Guide
Release 9.15
March 2019
Notices and Privacy
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 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
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
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
Upgrades....................................................................................................................................... 55
Upgrade Banner Integration API.................................................................................................55
Upgrade Banner Student API..................................................................................................... 56
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
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:
• 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.
Software requirements
The application has the following software requirements.
Oracle database
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.
The application is supported on the following application server and operating system combinations.
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.
– 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:
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
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.
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.
Procedure
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.
The Ellucian Messaging Adapter needs access to the Student and Integration APIs, to
RabbitMQ, and the Internet to access Ethos through HTTPS.
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.
Note: Other configurations may be supported depending on Network Load Balancing (NLB).
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.
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
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.
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.
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.
GURTRCK table
GUID generation through GURGUID is driven by the GURTRCK table. GURTRCK records will be
populated during the Ethos DB upgrade.
• GURTRCK_TABLE – Specifies the table for which the GUID needs to be generated.
• GURTRCK_OBJECT_TYPE - Indicates the purpose of the record.
EXECUTE gokguid_util.set_parallel(
p_parallel_threads => 8,
p_parallel_threshold => 1000000);
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:
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
‘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.
The parameters for the GUID generation process (GURGUID) can be entered in the GJAPCTL
screen in Banner.
Values:
• S - Serial
– 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.
Default: S
• S - Student
• G - General
• P - Payroll
• N - Position Control
• F - Finance
• R - Financial Aid
• T - Accounts Receivable
• % - For all available modules
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)
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.
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.
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.
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.
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.
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 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.
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
Use the checklists to complete the required steps for a new installation of Banner Integration API
and Banner Student API.
– Unix on page 26
– Windows on page 27
• Update the version numbers on page 28
• Restore original roles for accounts modified on page 28
1. Install Integration API before installing Student API. Follow the steps in Install Banner
Integration API on page 22
– Unix on page 26
– Windows on page 27
• Update the version numbers on page 28
• Restore original roles for accounts modified on page 28
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.
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.
Procedure
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.
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.
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’.
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:
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.
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:
Procedure
start versionupdate
2. Review the versionupdate listing.
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
Procedure
Note: You must have a valid application server account to deploy into the application server
container (Tomcat or WebLogic).
Procedure
Note: For Unix, make sure the ant file is executable. For example, chmod +x ant.
Example:
ban9temp $ cd installer
ban9temp/installer $ ./ant
TEST/
|--> applicationname/
|--> Catalog/
|--> shared_configuration/
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:
To install the installer into the product home directory, perform the following steps:
Procedure
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
On Unix:
[]: Current_home_directory/banner_test_homes/applicationname
On Windows:
[]: c:\banner_test_homes\applicationname
[]: 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.
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.
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.
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.
If you are installing the product in a Multi-Entity Processing environment, change the database
proxy setting.
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.
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"
} }
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.
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:
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.
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.
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
On Unix:
$ bin/systool war
On Windows
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.
For more information about enabling HTTPS support for web applications, see your application
server documentation.
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.
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
<ResourceLink global="jdbc/bannerDataSource"
name="jdbc/bannerDataSource"
type="javax.sql.DataSource"/>
<ResourceLink global="jdbc/bannerSsbDataSource"
name="jdbc/bannerSsbDataSource"
type="javax.sql.DataSource"/>
For Tomcat 8
h) Copy the Oracle JDBC jar file (ojdbc6.jar and 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.
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>.
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=
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.
This is an optional step that enables you to monitor or debug the application.
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
-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.
If you choose to install the application on a WebLogic server, you need not install it on Tomcat.
Ensure that the WebLogic prerequisites are fulfilled before configuring your WebLogic server.
Procedure
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.
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:
fi
fi
You need not create a WebLogic machine definition again if you have already created a machine
earlier.
Procedure
If you previously created a WebLogic server for the application, you can use the same server and
skip this step.
Procedure
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.
13. In the Change Center frame, click Activate Changes.
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.
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.
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.
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
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
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.
• 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.
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
Procedure
1. Change the name of the WAR file to remove the version number.
For example: Change
applicationname/current/dist/
applicationname-9.15.war
To
applicationname/current/dist/
applicationname.war
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.
Procedure
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.
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.
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.
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
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.
Procedure
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
Status: 200 OK
"applicationName": "applicationname",
"applicationVersion": "9.15"
Upgrades
Use the checklists to complete the required steps to upgrade Banner Integration API and Banner
Student API.
– Modify Ellucian Ethos Integration configuration for Student and Integration API endpoints on
page 60
• ILP Requirements on page 60
– Unix on page 26
– Windows on page 27
• Update the version numbers on page 28
• Restore original roles for accounts modified on page 28
• 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
– Modify Ellucian Ethos Integration configuration for Student and Integration API endpoints on
page 60
– Unix on page 26
– Windows on page 27
• Update the version numbers on page 28
• Restore original roles for accounts modified on page 28
• 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
4. Customize the WAR file on page 29
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.
• 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.
jmx {
exported {
log4j = "IntegrationApi-log4j"
}
}
log4j = {
String loggingFileDir = (System.getProperty('catalina.base') ?:
'target')
You will be instructed to make this change when installing the Integration API application.
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.
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:
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.
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 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.
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.
Shut down Tomcat and manually undeploy any previously deployed versions of the application on
your Windows systems.
Procedure
Insert the name of the application you want to remove for xxx. For example:
4. Remove the associated WAR file for each of the applications removed in the previous step: del
%CATALINA_HOME%\webapps\war_file_name /q.
Procedure
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).
Procedure
cd /MIDDLEWARE_HOME/user_projects/domains/base_domain/config
To correct the error, you must run the Oracle Weblogic patch to enable JPA 2.0 in Weblogic 10.3.6.
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:
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.
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.
• 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.
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
Courses
You can view Elevate courses on the following forms. You cannot perform any inserts, updates, or
deletions for Elevate courses.
Sections
You can view Elevate sections on the following forms. You cannot perform any inserts, updates, or
deletions for Elevate sections.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
'SB_SCHEDULE_VBS',
1,
sysdate,
user,
'nvl(SSBSECT_INTG_CDE,''x'') !
= ''ELEV8'''
'SB_CATALOG_ELEVATE_VBS',
2,
sysdate,
user,
and vbs.scrintg_crse_numb
= scbcrky_crse_numb
and vbs.scrintg_intg_cde
= ''ELEV8'' )'
'SB_SCRINTG_ELEVATE_VBS',
3,
sysdate,
user,
and vbs.scbcrse_crse_numb
= scbcrky_crse_numb
and
upper(nvl(vbs.scbcrse_data_origin,''X''
= ''ELEVATE'' )'
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.
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.
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.
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.
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.
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
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.
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.