1. Payments Installation Checklist
  2. Payments Installation Checklist
  3. Checklist for Installation on WebLogic Server

Checklist for Installation on WebLogic Server

Below are the list of steps to validate Server Configuration post successful installation of Oracle Banking Payments:
  1. Check the WebLogic version, JDK version on the Application server and Oracle Client version. The versions should be as per the latest certified version specified in the Release document.
  2. Below WebLogic, parameters should be checked as part of Oracle Banking Payments Installation for the WebLogic Domain created.
    1. Under Domain--> Configuration Tab --> Web Applications
    2. Options 'JSP Compiler Backwards Compatible’ and ‘Archived Real Path Enabled' should be checked
  3. Missing Server Id setup at server start-up for single server or cluster installations.
    Identify the Managed Server in which the Application EAR is deployed
    1. Login to the WebLogic Console
    2. Navigate to Environment --> Servers
    3. From the List of Servers, locate and click on the Managed Server in which the Application EAR is deployed

    Figure 2-1 Managed Server

    Description of Figure 2-1 follows
    Description of "Figure 2-1 Managed Server"
    Verifying Arguments for Reference Number Generation
    1. After clicking the Managed Server, navigate to ‘Server Start’ tab under the ‘ConfigurationTab’
    2. Verify the Arguments as shown below:

      -Dserver.id=1

    3. In case of cluster setup, each managed server, which is part of the cluster where the application is deployed, should have a different server id.

      For eg for Managed server, “Server1” the value should be given as

      -Dserver.id=1

      For Managed server Server2, the value should be given as

      -Dserver.id=2

      Different values can be given for managed server upto 99.

      Note:

      Parameter ‘-Dserver.id=1’ is required for the Reference Number Generation in Oracle Banking Payments Transaction screens. If not set, Oracle Banking Payments Transaction screens on launch will report Error on click of NEW.

      Figure 2-2 Server Start

      Description of Figure 2-2 follows
      Description of "Figure 2-2 Server Start"
  4. JMS Load Balancing Configuration

    For each of the Distributed Queue Connection Factory, disable the “Server Affinity” flag. This ensures that the messages get distributed uniformly across all the managed servers in a cluster.

    Figure 2-3 Load Balance


    Description of Figure 2-3 follows
    Description of "Figure 2-3 Load Balance"

  5. Non Transactional Datasource Configuration

    Datasource which do not have the “Supports Global Transactions” flag enabled are referred as Non-Transactional Datasource, as they do not come under the Container/Server managed transactions.

    Figure 2-4 Settings for jbdc/fcjdevDS

    For such Datasources, the inactive connection timeout seconds must be configured to a positive value. This helps to avoid the Connection Leak scenario. The suggested value is 30 seconds.

    Figure 2-5 Settings for jbdc/fcjdevDS


    Description of Figure 2-5 follows
    Description of "Figure 2-5 Settings for jbdc/fcjdevDS"

  6. Transactional Datasources Configuration

    Datasource for which the “Supports Global Transactions” flag is enabled referred as Transactional Datasource, as they come under the Container/Server managed transactions.

    Figure 2-6 Settings for jbdc-fcjdevDS_GTXN


    Description of Figure 2-6 follows
    Description of "Figure 2-6 Settings for jbdc-fcjdevDS_GTXN"

    For such data sources ensure that “Logging Last Resource” option is selected.

    Figure 2-7 Settings for jbdc-fcjdevDS_GTXN


    Description of Figure 2-7 follows
    Description of "Figure 2-7 Settings for jbdc-fcjdevDS_GTXN"

    “Inactive Connection Timeout” seconds must be set to 0. For the transactional Datasources as they participate in the container transaction, the timeout is governed by the JTA timeout seconds.

  7. Data Source Setup Verification
    1. Navigate to the Data Sources Configuration
    2. Below Data Sources must be mapped in the Data Sources Configuration
      1. Jdbc/fcjdevDS
      2. Jdbc/fcjdevDS_GTXN
      3. Jdbc/fcjdevDS_XA
    3. Additional Data Sources for Co-deployed
      1. jdbc/fcjdevDS_ASYNC

      Figure 2-8 Configuration

      Description of Figure 2-8 follows
      Description of "Figure 2-8 Configuration"
    4. Below listed Data Sources must be configured as NXA (Please refer to the below screen-shot for Jdbc/fcjdevDS_GTXN)
      1. Jdbc/fcjdevDS
      2. Jdbc/fcjdevDS_GTXN
      3. Jdbc/fcjdevDS_ASYNC
    5. Below listed Data Sources must be configured as XA
      1. Jdbc/fcjdevDS_XA

      Figure 2-9 Connection Pool

      Description of Figure 2-9 follows
      Description of "Figure 2-9 Connection Pool"
    6. Below options must be enabled for the GTXN Data Source - Jdbc/fcjdevDS_GTXN
      1. Supports Global transactions
      2. Logging Last Resource

      During creation of this datasource a table will be created in the connected database with the table name as WL_LLR_||’managed_server_name'

      Here the managed server will be the name of the target server associated with the datasource.

      For JDBC LLR 2PC transactions, if the transaction data is too large to fit in the LLR table, the transaction will fail with a rollback exception during commit. This can occur if your application adds many transaction properties during transaction processing. In this case, the database administrator can drop the existing table and create a new LLR table with the same name or alter the column with larger recSize value for RECORDSTR data column. The RECORDSTR data column must be the DBMS's variable string column type with the DBMS's maximum size. In this way, the DBMS allocates as much space as the data needs for a given row.

      Figure 2-10 Transaction

      Description of Figure 2-10 follows
      Description of "Figure 2-10 Transaction"
  8. Target Server for Datasources created
    1. If Payments EAR is deployed with embedded Scheduler, all datasources should point to the single Managed Server, where the application is deployed.
    2. If Payments EAR and Scheduler EAR are deployed on two different Servers.
      1. Below datasources should be targeted to Managed Server where application is deployed.

        jdbc/fcjdevDS

        jdbc/fcjdevDS_GTXN

        jdbc/fcjdevDS_XA

      2. Below datasources should be targeted to Managed Server where Scheduler is deployed.

        jdbc/fcjdevDS

        jdbc/fcjdevDS_XA

  9. Verifying data in SMTB_MODULES_GROUP Table
    1. JNDI Names Input during Installation process must be verified with records in the SMTB_MODULES_GROUP table.
    2. JNDI name provided here should be created on console.

    Figure 2-11 Below is the screen-shot of Data Input during installation

    Description of Figure 2-11 follows
    Description of "Figure 2-11 Below is the screen-shot of Data Input during installation"

    Figure 2-12 Below is the screen-shot of records in the SMTB_MODULES_GROUP table

    Description of Figure 2-12 follows
    Description of "Figure 2-12 Below is the screen-shot of records in the SMTB_MODULES_GROUP table"
  10. All queues mentioned in the Resource List should be mandatorily created. For all queues where Error queue needs to be defined, the below setting should be done.
    1. ‘Expiration Policy’ should be maintained as ‘Redirect’ and ‘Error Destination’ as the error Queue. Keep Redelivery Limit as zero.

      Figure 2-13 Delivery Failure

      Description of Figure 2-13 follows
      Description of "Figure 2-13 Delivery Failure"
  11. In case of Standalone and co-deployed setup for Payments, the below external queues should have the setup as mentioned:

    jms/SNCK_RES_IN

    jms/SNCK_RES_BKP_IN

    jms/FP_SNCK_RES_IN

    jms/FP_SNCK_RES_BKP_IN

    jms/EXT_PRICE_RES_IN

    jms/EXT_PRICE_RES_BKP_IN

    jms/EXTACSYS_REQ_IN

    jms/ECA_RES_BKP_IN

    jms/FP_ECA_RES_BKP_IN

    jms/ECA_RES_IN

    jms/ACC_ENTRY_RES_BKP_IN

    jms/ECR_RES_IN

    jms/ECR_RES_BKP_IN

    jms/EXTRATESYS_REQ_BKP_IN

    jms/EXTRATESYS_REQ_IN

    1. Options Expiry Policy should be maintained as Redirect and error destination as Error queue in Delivery Failure. Keep Redelivery Limit as zero.
    2. In Tab Overrides, value for ‘Time-to-Live Override” should be maintained as 2000.
  12. In case of co-deployed setup, for external queue MDB_QUEUE_RESPONSE, check if
    1. Options Expiry Policy is maintained as Redirect and error destination asjms/ACC_ENTRY_RES_BKP_IN in Delivery Failure. Redelivery Limit should be 0.
    2. In Tab Overrides, value for ‘Time-to-Live Override” should be maintained as 2000.
  13. Check if following Gateway ears are deployed on the Application Server for co-deployed setup.
    1. GW EJB
    2. GW MDB
  14. SYSTEM’ user should be present and debug should be enabled in case debugs needs to be generated for checking the response error from FCUBS.
  15. User role should be granted to SYSTEM user for the branch from where transaction is posted to MDB.
  16. Check the maintenance for tables
    • PMTM_JOB_PARAM

      1. For Parameter PM.CTX.PROVIDER property maintain the below value“t3://Weblogic_IP:Server_Port” or t3://Host Name:Server_Port Here Host Name is the name of the Application Server or IP of the Application Server.

        Server_Port is the listen port configured on the application Managed Serverwhere application is deployed.

      2. For parameter PM.CTX.FACTORY value should be weblogic.jndi.WLInitialContextFactory.
    • PMTM_SYSTEM_PARAMETERS
      1. For PARAM_NAME “PM.CTX.FACTORY”, update the PARAM_VALUE as ‘weblogic.jndi.WLInitialContextFactory’.
      2. For PARAM_NAME “PM_CTX_PROVIDER”, update the PARAM_VALUE for Non-Cluster setup as “t3://Weblogic_IP:Server_Port” or “t3://HostName:Server_Port” and for Cluster setup as “t3://HOST NAME1: PORT 1, HOST NAME2:PORT 2”
        1. Here Host Name is the name of the Application Server or IP of the Application Server.
        2. Server_Port is the listen port configured on the application Managed Server where application is deployed.
      3. For PARAM_NAME “PM.CTX.CONNFACTORY” the appropriate connection factory needs to be provided which is created in JMS Server for e.gjms/PMQCF.
      4. For PARAM_NAME “C2B_FILE_PATH”, give the C2B path maintained in the Application server.
      5. For PARAM_NAME “DD_FILE_PATH” property, give the DD path maintained in the Application server.
      6. For PARAM_NAME “DEBUG_PATH” property, give the PM DEBUG path maintained in the Application server.
      7. For PARAM_NAME “DISPATCH_PATH” property, give the DISPATCH path maintained in the Application server.
    • CSTB_PARAM
      1. Check if the below parameters PM.CTX.FACTORY, PM_CTX_PROVIDERand PM.CTX.CONNFACTORY exist in CSTB_PARAM. In case parameters exists, it should have the same value as in PMTM_SYSTEM_PARAMETERS. The parameters need not be maintained in case it’s already maintained in PMTM_SYSTEM_PARAMETERS.
    • CSTM_EXTERNAL_SERVER_DETAILS
      1. For field “CONTEXT_PROV_URL”, update the values for Non-Cluster setup as “t3://Weblogic_IP:Server_Port” or “t3://HostName:Server_Port” and for Cluster setup as “t3://HOST NAME1: PORT 1, HOST NAME2:PORT2” in web-logic application server.
      2. Value for QUEUE_FCTRY_JNDI should be ‘jms/PMQCF’
      3. Value for CACHE_QUEUE_JNDI should be ‘jms/CACHE_TOPIC’
  17. Please ensure the topic CACHE_TOPIC is created and present in the weblogic JMS Server. In case of cluster and non-cluster setup, the ‘Forwarding policy’ of the distributed Topic should be“Replicated” for the uniform Distributed Topic, otherwise the Caching would not work properly.

    Figure 2-14 Configuration - General

    Description of Figure 2-14 follows
    Description of "Figure 2-14 Configuration - General"
  18. If External JSUIXML path is checked as required during property creation, all UIXML and JS files(plus copy of old Rolled-up JSUIXML) should be copied to the external path after EAR creation.
  19. All EMS folders should be created on the Application server with full rights.
  20. Check if the value for below EMS properties are correctly defined in fcubs.properties.

    EMS_INIT_CTX_FACT=weblogic.jndi.WLInitialContextFactory

    1. Non Cluster Setup

      EMS_PRVDR_URL= t3://Weblogic_IP:Server_Port

      t3://Weblogic_IP:Server_Port” or “t3://Host Name:Server_Port”

      1. Here Host Name is the name of the Application Server or IP of the Application Server.
      2. Server_Port is the listen port configured on the application Managed Server where application is deployed.
    2. Cluster Setup

      In case of external load balancer, it should be the Host Name or IP and port of the Load balancer.

      EMS_PRVDR_URL= t3://Weblogic_IP:Server_Port

      In case of internal load balancer, specify the Host name and IP as below of all managed servers used in the Cluster

      EMS_PRVDR_URL= t3://HOST NAME1: PORT 1, HOST NAME2:PORT 2

  21. Debug paths should be created on the Application server with full rights. Data Store tableCSTB_DEBUG_USERS should be populated with value Y if debug is to be generated for a logged in user.
  22. Below maintenance should be done for both Co-deployed and Standalone. Details can be checked in FCUBS-Oracle Banking Payments Integration document.
    1. Sanctions System Maintenance (PMDSNCKM)
    2. ECA System Maintenance (PMDECAMT)
    3. Accounting System Maintenance (PMDACCMT)
    4. Queue Connection Profile Maintenance (PMDQPROF)

Parent topic: Payments Installation Checklist