3 Backend System Administration and Logging

The following graphic illustrates the names of the actual RIB files and shows their location in the deployment picture.

Surrounding text describes compdiststruc.png.

rib-<app>-adapters.xml

This file specifies all the adapter instances needed by RIB to interact with an application. Each rib-<app_name> has its own rib-<app-name>_adapter.xml.

The file is located in the rib-home/application-assembly/rib-<app> directory. After deployment, it is found in the path $application_instance_home, where $application_instance_home is the WebLogic instance path where the application is deployed.

The following sections describe the standard RIB defined adapter types.

<subscribers> elements

The <subscribers> elements consist of multiple occurrences of <message-driven> elements that define all the subscribers available for a particular application. Each <message-driven> element consists of ID (the ID for the adapter) and initialState (the initial state of the adapter) attributes. The initialState attribute for <message-driven> adapters accepts two values: running and stopped.

<subscribers>
  <message-driven id="ASNIn_sub_1" initialState="running"/>
  <message-driven id="ASNOut_sub_1" initialState="running"/>

Note:

The only valid states are running and stopped, and they are case sensitive.

<publisher> elements

The <publisher> elements consist of multiple occurrences of <timer-driven> or <request-driven> elements, used to define all the publishers available for a particular application.

<timer-driven>

This element is used to define publishers for PL/SQL (RMS, RFM, and RWMS) applications. Each <timer-driven> element consists of an id (specifies id for adapter), initialState (specifies the initial state of the adapter) and timeDelay (delay after which the GETNXT needs to be called each time) attributes. The initialState attribute for <timer-driven> adapters accepts two values: running and stopped. This consists of an element called <timer-task> which specifies the implementation details of the adapter. The <timer-task> element specifies the GETNXT implementation through the <class> element.

<publishers>
    <timer-driven id="Alloc_pub_1" initialState="running" timeDelay="10">
          <timer-task>
               <class name="com.retek.rib.app.getnext.impl.GetNextTimerTaskImpl"/>
                       <property name="maxChannelNumber" value="1" />
          </timer-task>
    </timer-driven>

<request-driven>

This element is used to define publishers for Java EE (Oracle Retail Price Management (RPM), Oracle Retail Store Inventory Management (SIM), and Oracle Retail Advance Inventory Planning (AIP) applications. Each <request-driven> element consists of ID (specifies ID for adapter) and initialState (specifies the initial state of the adapter) attributes. The initialState attribute has a value of notConfigurable.

<publishers>
      <request-driven id="ASNOut_pub_1" initialState="notConfigurable"/>
      <request-driven id="DSDReceipt_pub_1" initialState="notConfigurable"/>

<hospital> element

This element specifies hospital related adapter information. The structure is very similar to the <publisher> element except that the name and value attributes in the property element define the different hospital adapter types.

<hospitals>
       <timer-driven id="sub_hosp_0" initialState="running" timeDelay="10">
              <timer-task>
                    <class name="com.retek.rib.j2ee.ErrorHospitalRetryTimerTask"/>
                           <property name="reasonCode" value="SUB"/>
              </timer-task>
       </timer-driven>

rib-<app>-adapters-resource.properties

These properties internationalize strings for internal RIB adapter key names.

Example:

sub_all.name=Subscribers
sub_all.desc=Manages all subscribers at the same time.

ASNIn_sub_1.name=ASNIn Subscriber, channel 1
ASNIn_sub_1.desc=Subscriber for the ASNIn family through channel 1.

ASNOut_sub_1.name=ASNOut Subscriber, channel 1
ASNOut_sub_1.desc=Subscriber for the ASNOut family through channel 1.

rib-<app>-plsql-api.xml

This configuration file is specific to RMS, RFM, and RWMS. RIB interfaces with RMS, RFM, and RWMS through two database procedures: GETNXT and CONSUME. This file contains the calling signatures for these procedures, the parameters to be configured before calling these procedures, and the implementation class for handling the objects returned from these procedures.

rib-<app>.properties

These are application specific configurable properties. These properties can be edited from the rib-admin-gui.

Property Name and Default Value	Description
facility_id defaultValue = "facility_id";	This property is used to refer to the warehouse routing configuration. The value of this property is used to construct the facility type
dc_dest_id defaultValues = 1,2 and 3;	This property is used to refer to the warehouse distribution center. Destination ID
facility_type_default defaultValue = "PROD";	Specifies the default facility type to be used by RWMS publishing adapters for calls to RWMS.
enableDynamicAdapterInstance Selection	This flag is used to enable the dynamic adapter selection feature for a particular rib-<app>. By default this flag is set to false except rib-ext.
disableLogLevelUpdatesFor Adapter	Drop down to update log levels are restricted (read-only) for adapters whose names are configured in rib-<appName>.properties file. Log level change for any adapters can be restricted (read-only) by adding name of adapters as comma (",") separated value against key disableLogLeve-lUpdatesForAdapter in rib-<appName>.properties file. Example: disableLogLevelUpdatesForAdapter= Customer_sub,Customer_pub. Below are list of properties file that are updated for current release rib-rsys.properties rib-rce.properties rib-ext.properties
drop-messages-of-types	Undesired message types can be filtered in RIB subscriber. This is configurable setting. Steps to set the Add list of msg types (comma separated) which needs to be dropped in rib-<app>.properties file. Format to set the property is: for.<adapter_name>.drop-messages-of-types= msgType1,msgType2 For example, for.MerchHier_sub.drop-messages-of-types= CLASSCRE,CLASSDEL RIB subscriber drops the message type(s) set in properties file. By default it subscribes all the message types.

rib-system.properties

All properties for RIB have been classified into kernel properties and application properties. This file contains kernel properties that are used specifically for the functioning of the RIB kernel. They are mostly related to hospital retry configuration, payload locations, or alerting.

Property Name and Default Value	Description
hospital_attempt_max defaultValue = "5";	This property refers to the maximum number of attempts to try to push this record through RIB automatically. Once this retry count is exceeded, the message remains in the RIB Hospital DB but is no longer retried automatically
hospital_attempt_delay defaultValue = "10";	This property refers to the value (in seconds) used to calculate the next attempt time.
hospital_attempt_delayIncrement defaultValue = "10";	This property refers to the value (in seconds) used to calculate the next attempt time. The next attempt time is calculated as: hospitalAttemptDelay + (hospitalAttemptDelyIncrement * attempt count). This is done so that the delay between each attempt is longer than the previous delay.
numOfRecordsToRetry defaultValue = "20";	This property refers to the maximum number of RIB Hospital records to be retried in one RIB Hospital retry attempt.
xml_schema_base_url defaultValue = "http://localhost:8888/rib- func-artifact";	This property refers to the location of web application (rib-func-artifact) which has RIB related XML Schema (XSD) files.
log.default.file_path defaultValue=$DOMAIN_HOME/servers/$$SERVER NAME/logs/$APP_NAME	This property refers to the location where log files are created by the RIB application. By default this location is in the logs/app_name directory inside the WebLogic instance home where the app has been installed.
mail_smtp_host defaultValue = "mail.smtp.host";	This property is used to identify the smtp host from which to send out emails.
mail_smtp_port defaultValue = "25";	This property is used to identify the smtp port from which to send out emails.
mail_smtp_from defaultValue = "admin@company.com";	This property refers to the email id that the RIB platform needs to use to send the emails for administrative purposes.
war_http_port defaultValue = "9080";	This property refers to the port number used by the web based Hospital Retry Administration Tool.
wls.wallet.file.location defaultValue=$DOMAIN_HOME/serves/$SERVER NAME	This property refers to the wallet file that contains the user name/password details for connecting to the WebLogic instance. The user should not change this value.
wls.wallet.map.name defaultValue=rib-rms-wls	This property refers to the map name that is stored in the wallet file for connecting to the WebLobic instance. The user should not change this value.
wls.wallet.user.alias defaultValue=rib-rms-wls- user-alias	This property refers to the alias stored in the wallet file for connecting to the WebLogic instance. The user should not change this value.
oauth2.default.authorizationServerUrl	IDCS token URL gets written to the rib-system.properties at compile time with this format oauth2.default.authorizationServerUrl=https://idcs-c3bb6417e4904132beebfa6c440fcce4.identity.c9dev1.oc9qadev.com/oauth2/v1/token This can be edited at runtime from GUI.
slave.plsql.publisher.service.endpoint.url slave.plsql.injector.service. endpoint.url	End point URLs for RMS primary-secondary ReST communication.The user can edit these values from GUI at runtime.
injector.service.endpoint.url injector.service.security. policyname	End point URL and policy name for soap-app and rest-app. The user should not edit these values.
remote.plsql.enabled=true remote.plsql.slave.app=false	These properties are used in the RIB-RWMS and RIB-RMS hybrid cloud installation. The primary and secondary configuration determination is made based on these flags. The user should not edit these flag values.

rib-integration-flows.xml

This file is the single source of all values used by the RIB Application Builder tools to define and configure the JMS topics as well as perform start and stop activities, including subscriber checks. For RIB deployments, this file should not be edited.

This file is packaged and deployed as part of the rib-func-artifacts war file.

Example:

<message-flow id="1">
  <node id="rib-rms.Alloc_pub" app-name="rib-rms" adapter-class-def="Alloc_pub" type="DbToJms">
    <in-db>default</in-db>
    <out-topic>etAllocFromRMS</out-topic>
  </node>
  <node id="rib-tafr.Alloc_tafr" app-name="rib-tafr" adapter-class-def=
"Alloc_tafr" type="JmsToJms">
    <in-topic>etAllocFromRMS</in-topic>
    <out-topic name="topic-name-key-iso">etStockOrdersISO</out-topic>
    <out-topic name="topic-name-key-wh">etStkOrdersFromRIBToWH{*}</out-topic>
  </node>
  <node id="rib-sim.StockOrder_sub" app-name="rib-sim" adapter-class-def="StockOrder_sub" type="JmsToDb">
    <in-topic>etStockOrdersISO</in-topic>
    <out-db>default</out-db>
  </node>
  <node id="rib-rwms.StockOrder_sub" app-name="rib-rwms" adapter-class-def="StockOrder_sub" type="JmsToDb">
    <in-topic>etStkOrdersFromRIBToWH1</in-topic>
    <out-db>default</out-db>
  </node>
</message-flow>

rib-deployment-env-info.xml

This file is the single source of all values used in the RIB Application Builder tools and is the only (or should be the only) file that requires editing for using them.

For example, when the RIB Application Builder is used to extract error hospital tables from an application schema, this file supports those tables.

The RIB Application Builder tools can be executed independently. The file must be edited manually.

app-in-scope-for-integration

This section defines what applications are in scope for this environment.

Example:

<app-in-scope-for-integration>
  <!--app id="rms" type="master-plsql-app" /-->
  <app id="rms" type="plsql-app" />
  <!-- The below configuration is for rwms as a master-plsql-app, use this when RIB is on cloud and RWMS is on-prem-->
  <!--app id="rwms" type="master-plsql-app" /-->
  <!--app id="rwms2" type="master-plsql-app" /-->
  <!--app id="rwms3" type="master-plsql-app" /-->
  <!--app id="rwms4" type="master-plsql-app" /-->
  <app id="rwms" type="plsql-app" />
  <app id="tafr" type="tafr-app" />
  <app id="sim" type="javaee-app" />
  <app id="ext" type="javaee-app" />
  <app id="rpm" type="javaee-app" />
  <app id="aip" type="javaee-app" />
  <app id="rfm" type="plsql-app" />
  <app id="rob" type="rest-app" />
  <app id="lgf" type="soap-app" />
  <app id="ocds" type="soap-app" />
</app-in-scope-for-integration>

rib-jms-server

This section defines the JMS server information.

Example:

<jms-server-home>linux1@linux1:/home/oracle/oracle/product/12.1.0.2/db_1
</jms-server-home>
<jms-url>jdbc:oracle:thin:@linux1:<port>:ora12c</jms-url>
<jms-port><port></jms-port>
<jms-user-alias>jms1_user-name-alias</jms-user-alias>

rib-application-server

This section defines the WebLogic Server information.

Example:

<weblogic-domain-name>base_domain</ weblogic-domain-name >
<weblogic-domain-home>soa1@linux1:/home/soa1/Oracle/Middleware/user_projects/domains/base_domain</weblogic-domain-home>
<weblogic-admin-server-port protocol="http">7001</weblogic-admin-server-port>
<java-home>/usr/java/jdk1.8</java-home>

rib-javaee-containers

This section defines the WebLogic instances for each of your rib-<app> applications that are in-scope.

Example:

<wls id="rib-rms-wls-instance">
  <wls-instance-name>rib-rms-wls-instance</wls-instance-name>
  <wls-instance-home>soa1@linux1:/home/soa1/Oracle/Middleware/user_projects/domains/base_domain/servers/rib-rms-wls-instance</wls-instance-home>
  <wls-listen-port protocol="http">7003</wls-listen-port>
  <wls-user-alias>rib-rms-wls-user-alias</wls-user-alias>
</wls>

rib-applications

This section defines the rib-<app> specific information for each applicable rib-<app>.

Example 1: RIB-RMS (for app-type=PL/SQL)

<rib-app id="rib-rms" type="plsql-app">
  <deploy-in refid="rib-rms-wls1" />
  <rib-admin-gui>
    <web-app-url>URL to the rib admin gui web app.</web-app-url>
    <web-app-user-alias>rib-rms_rib-admin-gui_web-app-user-alias
</web-app-user-alias>
  </rib-admin-gui> 
  <notifications>
    <email>
      <email-server-host>mail.example.com</email-server-host>
      <email-server-port>25</email-server-port>
      <from-address>rib-email@example.com</from-address>
      <to-address-list>rib@example.com</to-address-list>
    </email>
    <jmx/>
  </notifications>
</rib-app>

Example 2: Application Database (for app-type=PL/SQL)

<app-database>
  <app-url> DB host URL for pl/sql application</app-url>
  <app-db-user-alias>rib-rms_app-database_user-name-alias</app-db-user-alias>
</app-database>

Example 3: Java EE application with JNDI information defined

<jndi>
  <url>t3://simhost.example.com:<port>/sim-app</url>
  <factory>weblogic.jndi.WLInitialContextFactory</factory> 
  <user-alias>sim_jndi_user-name-alias</user-alias>
</jndi>

Example 4: Error Hospital Database

<error-hospital-database>
  <hosp-url>jdbc:oracle:thin:@simdbhost.example.com:<port>:orcl</hosp-url>
  <hosp-user-alias>rib-rms_error-hospital-database_user-name-alias
</hosp-user-alias>
</error-hospital-database>

Example 5: RWMS Secondary App Information (for RWMS Hybrid Cloud)

<app id="rwms" type="soap-app">
  <end-point>
    <!-- URL of slave rwms  host  -->
    <url>http://slaverwmshost.example.com:9001</url>
    <!-- Supported security policy names =policyC(default) OR policyA -->
    <ws-policy-name>policyC</ws-policy-name>
    <user-alias>rib-rwms_ws_security_user-name-alias</user-alias>
  </end-point>
</app>

Example 6: Hybrid Cloud Installation (for app-type=soap-app) wherein RIB is on Cloud and Retail App is on Premise

<app id="sim" type="soap-app">
  <end-point>
    <url>http://simhost.example.com:9001/ApplicationMessageInjectorBean/
InjectorService</url>
    Supported security policy names = policyA OR policyB
    <ws-policy-name>policyC</ws-policy-name>
    <user-alias>rib-sim_ws_security_user-name-alias</user-alias>
  </end-point>
</app>

Example 7: Hybrid Cloud Installation (for app-type=rest-app) wherein RIB is on Cloud and Retail App is on Premise

<app id="rce" type="rest-app">
  <end-point>
    <url>http://rcehost.example.com:9001/rib-injector-services-web/resources/
injector/inject</url>
    <!-- Supported security policy names =policyC (default) OR policyA -->
    <ws-policy-name>policyC</ws-policy-name>
    <user-alias>rib-rce_ws_security_user-name-alias</user-alias>
  </end-point>        
</app>

log4j2.xml

The log4j2 Open Source software is used to control all RIB logging. This software requires the log4j2.xml file to configure the file name, logging level, and type of file used.

rib-app-builder-paths.properties

For RIB deployments, this file should not be edited.

rib-application-assembly-info.xml

This is a non editable file that describes the structure of the rib-<app>.ear and the resources it uses.

retail_service_config_info_ribserver.xml

This is a non editable file that describes the service related configuration used by rib-<app> to identify the relevant service implementations.

remote_service_locator_info_ribserver.xml

This is a non editable file that describes the JNDI related configuration used by rib-<app> to invoke remote EJBs hosted on Java retail apps (for example, RPM and SIM). This file is built at runtime, based on the information provided in rib-deployment-env-info.xml.

RIB Logging

All logging in RIB is through log4j2, the Apache Software Foundation's Open Source software. For details about log4j2 visit the Apache Software Foundation's log4j2 home page.

Log Level Recommendations

The logging level must be adjusted for the phase of the deployment. What is appropriate in development and test (DEBUG) is not appropriate in production (INFO). It is important to note that while the DEBUG logging level provides insight into the low-level processing occurring within the RIB, logging at such a low level comes at a cost. Specifically, such detailed logging is very CPU-intensive, and depending on the application server hardware configuration, the actual RIB message processing logic could be forced to wait for the CPU cycles being occupied by the detailed DEBUG logging, which will result in an increase in overall message processing time. In a production environment, the logging level must be set to the lowest level possible in order to ensure proper resource allocation to all RIB message processing logic.

There are some logs such as audit and timing that may be used differently at certain phases as well. Audit is either on (DEBUG) or off (INFO); the same is true with timings as described for the logging level above. To summarize once again, the lowest level of audit and timing logging should be used in a production environment.

As a rule, the appropriate level is INFO.

Changing Logging Levels

RIB use of log4j2 allows the control of logging levels to suit the deployment and situation. There are two methods of setting the logging levels: directly manipulating the log4j2.xml file using a text editor, and the RIB Administration GUI.

RIB Administration GUI

The RIB Administration GUI allows control of the logging levels for each adapter individually. It permits the change to affect only the runtime logging and is dynamic. It also provides the ability to persist the change so that the adapters retain that level when restarted. This is the recommended approach.

log4j2.xml Configuration File

The RIBLOGS log4j2.xml file can be directly edited. This requires that the adapters be bounced for the change to take effect. See the following sections for what to edit, as related to the type of log (RIBLOG, Timing Log, and so on).

Adapter Logging (RIBLOGS)

The RIB adapter code contains logging logic that writes all of RIB's runtime logs to the RIBLOG log files. The logs are written to the path <rib-application_instance_home>/logs/<rib-app>.

Example:

/u01/webadmin/Oracle/Middleware/user_projects/domains/base_domain/servers/rib-rms-wls-instance/logs/rib-rms

The RIBLOG file names are in this format: <adapter-instance-name>.rib.log.

Example:

Alloc_pub_1.rib.log
ASNIn_sub_1.rib.log
ASNOut_sub_1.rib.log

To enable this function, parameters must be set per adapter.

Be careful because there are multiple entries for each adapter instance in the log4j2.xml file. Search for the section of the log4j2.xml file:

<!--RIB Appender for adapterInstance: Alloc_pub_1-->

RIB Timing Logs

The RIB messaging components code is instrumental in logging timing entries on the internal activities whenever they create, transform, route, filter, or subscribe to messages on RIB. These timings logs are written using the log4j2 logging mechanism.

The timings log files follow the name convention <adapter-instance-name>.timings.log and are found in the same locations as the RIBLOGS.

Typically, one timings log file is created per component (EJB or other) that holds the entries for that component. These files are cumulative, meaning that they do not get overwritten with every initialization of the component, but they append new entries to the current information already recorded. The files do roll over after they reach a certain configurable size and backup files are created to preserve previous entries.

Each entry in the timings log represents a timestamp of a particular event in the RIB component, listing the date and time information, name of the component, thread ID and a distinct message for each event. The list of time stamped events includes such items as the start time and/or end time of the following actions:

Overall publication, subscription, routing, or transformation process
Calls to stored procedures (getnxt and consume)
Actual publication and subscription of messages to and from the JMS server
Calls to the RIB Hospital to check for dependencies and insert messages
Calls to other applications to process messages after subscription (injectors)

The log4j2.xml file must have the "level value" property set to DEBUG. This tag is not normally present in the standard log4j2.xml file, it must be added. The following example shows how and where.

Note that there are multiple entries for each adapter instance in the log4j2.xml file. Search for the section of the log4j2.xml file:

<!--Timings Logger for adapterInstance: -->".

Before:

<!--Timings Logger for adapterInstance: Order_pub_1-->
  <Logger additivity="false" name="rib-timings.Order_pub_1" level="info" />

After:

<!--Timings Logger for adapterInstance: Order_pub_1-->
  <Logger additivity="false" name="rib-timings.Order_pub_1" level="debug" />

RIB Audit Logs

RIB has an auditing feature that logs a message as it passes though the RIB infrastructure. Each messaging component can be set to write the message, and only the message, to a separate log file. This allows the tracing of message content from publication to subscription, and all steps, such as a TAFR, in between.

There are two benefits to this mechanism: the ability to audit each step, and the ability to create a recovery plan. The messages can be played back, without effort being spent to extract them from inside other more systemic log files.

Typically, one audit log file is created per component (EJB or other) that holds the entries for that component. These files are non rolling, meaning that they do get overwritten after they reach a certain configurable size. Customer has to take care to manage audit log file size.Audit logs has some performance impact so should be enabled only when there is need to save messages.

Refer to Chapter ”RIB Administrator GUI” for more information on setting the non-persistent log levels to persistent such as DEBUG and viewing audit logs in GUI.

The log4j2.xml can be edited to remove the <audit-entry> tag from the output and to have only the message in the file.

<Routing name="appender.audit.log.routing">
  <Routes pattern="$${ctx:AUDIT_ROUTING_KEY}">

    <!-- This route is chosen if ThreadContext has a value for AUDIT_ROUTING_KEY The value dynamically determines the name of the log file. -->
    <Route>
      <RollingFile name="Rolling-${ctx:AUDIT_ROUTING_KEY}" file-Name="servers/${sys:weblogic.Name}/logs/${main:appName}/${ctx:AUDIT_ROUTING_KEY}.audit.log" filePat-tern="servers/${sys:weblogic.Name}/logs/${main:appName}/${date:yyyy-MM}/${ctx:AUDIT_ROUTING_KEY}-%d{yyyy-MM-dd}-%i.audit.log.gz">
        <PatternLayout>
          <pattern>%d %-5p [%t] %C{2} (%F:%L) - %m%n</pattern>
        </PatternLayout>
        <Policies>
          <TimeBasedTriggeringPolicy interval="6" modulate="true" />
          <SizeBasedTriggeringPolicy size="10 MB" />
        </Policies>
      </RollingFile>
    </Route>
  </Routes>
  <IdlePurgePolicy timeToLive="600" timeUnit="seconds" />
</Routing>

Remove the "pattern" in the PatternLayout with %m%n

RIB also can log a set of audit logs used to audit all the events processed by RIB. To enable this function, parameters must be set per adapter.

Proceed cautiously because there are multiple entries for each adapter instance in the log4j2.xml file. Search for the section of the log4j2.xml file:

<!--Audit Logger for adapterInstance: ItemLoc_pub_1-->.

Before:

<!--Audit Logger for adapterInstance: ItemLoc_pub_1-->
  <Logger additivity="false" name="rib-audit.ItemLoc_pub_1" level="info" />

After:

<!--Audit Logger for adapterInstance: ItemLoc_pub_1-->
  <Logger additivity="false" name="rib-audit.ItemLoc_pub_1" level="debug" />

Sample Log Entry:

<audit-entry audit-time="2008.01.28 11.37.57,642">
<?xml version="1.0" encoding="UTF-8"?>
<RibMessages
    xmlns="http://www.oracle.com/retail/integration/rib/RibMessages"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.oracle.com/retail/integration/rib/RibMessages
    http://ribhost.example.com:7777/rib-func-artifact/integration/xsd/
RibMessages.xsd" >
  <ribMessage>
    <family>Banner</family>
    <type>BannerCre</type>
    <id>1</id>
    <ribmessageID>Banner_pub_1|2008.01.28 11:37:57.500|6936</ribmessageID>
    <publishTime>2008-01-28 11:37:57.500 CST</publishTime>
    <messageData>&lt;BannerDesc  xmlns=&quot;http://www.oracle.com/retail/integration/payload/BannerDesc&quot;  xmlns:ribdate=&quot;http://www.oracle.com/retail/integration/payload/RIBDate&quot;xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;xsi:schemaLocation=&quot;http://www.oracle.com/retail/integration/payload/BannerDesc http://ribhost.example.com:7777/rib-func-artifact/payload/xsd/BannerDesc.xsd
http://www.oracle.com/retail/integration/payload/RIBDate
http://ribhost.example.com:7777/rib-func-artifact/payload/xsd/RIBDate.xsd&quot;&gt;  &lt;banner_id&gt;1&lt;/banner_id&gt;  &lt;banner_name&gt;B&amp;amp;M&lt;/banner_name&gt;&lt;/BannerDesc&gt;</messageData>
    <customData></customData><customFlag>F</customFlag>
  </ribMessage>
</RibMessages>

Other RIB Management Logs

The following are examples of other RIB management logs.

deploy.rib.log

This log will track the source rib-app-builder home that pushed the changes to this WebLogic instance. For example:

Uploading configuration file from machine(ribhost.example.com)
dir(/stage/Rib160030-ms7.1/Rib1600ForAll16xxApps/rib-home/deployment-home/bin/../../../rib-home) at(Mon Jan 28 11:15:57 PST 2016).

management.rib.log

RIB maintains a management log which is used to keep track of the WebLogic instance on the whole.

This log usually is written during the startup of a WebLogic instance. The recommendation is that each rib-app be deployed in a separate WebLogic instance, so management logs are specific to a rib-app.

The management log writes RIB information common to all the components like loading property files and creating logging files.

Example:

2008-02-01 14:33:23,928 [AJPRequestHandler-RMICallHandler-6] DEBUG
com.retek.rib.management.adapters.client.action.StopAdapterAction - Invoking
operation to stop the adapters
2008-02-01 14:33:23,928 [AJPRequestHandler-RMICallHandler-6] DEBUG
com.retek.rib.monitor.engine.MBeanAbstractFactory - Invoking MBean operation
domain(rib-rms) objectNameProperty(level=adapters,type=sub,name=Receiving_sub_1)
methodName(stop) parameter([Ljava.lang.Object;@1452a1)
signature([Ljava.lang.String;@3d06a4).

global.rib.log—Example

2008-02-06 10:14:26,688 [AJPRequestHandler-RMICallHandler-7] DEBUG
retek.com.retek.rib.ui.view.tags.IteratePropertyTag.com.retek.rib.management.adap
ters.model.AdapterTypes - Invoking Operation returnStatusForAll of MBean.
2008-02-06 10:14:26,777 [AJPRequestHandler-RMICallHandler-7] DEBUG
retek.com.retek.rib.ui.view.tags.IteratePropertyTag.com.retek.rib.monitor.engine.M
BeanAbstractFactory - Invoking MBean operation domain(rib-rms)
objectNameProperty(level=types,type=pub,name=pub_all)
methodName(returnStatusForAll) parameter(null) signature(null).
2008-02-06 10:14:26,780 [AJPRequestHandler-RMICallHandler-7] DEBUG
retek.com.retek.rib.ui.view.tags.IteratePropertyTag.com.retek.rib.management.adapt
ers.model.AdapterTypes - Operation returnStatusForAll for type pub invoked
successfully :<type name="pub"><adapter id="Alloc_pub_1"  name="Alloc Publisher,
channel 1" state="running" /><adapter id="SeedData_pub_1"  name="SeedData
Publisher, channel 1" state="running" /><adapter id="SeedObj_pub_1" name="SeedObj
Publisher, channel 1" state="running" /><adapter id="WOOut_pub_1" name="WOOut
Publisher, channel 1" state="running" /><adapter id="Banner_pub_1" name="Banner
Publisher, channel 1" state="running" /><adapter id="Transfers_pub_1"
name="Transfers Publisher, channel 1" state="running" /><adapter
id="RcvUnitAdj_pub_1"  name="RcvUnitAdj Publisher, channel 1" state="running" /><adapter
id="Vendor_pub_1"  name="Vendor Publisher, channel 1" state="running" /><adapter
id="WH_pub_1"  name="WH Publisher, channel 1" state="running" /><adapter
id="RTVReq_pub_1"  name="RTVReq Publisher, channel 1" state="running" /><adapter
id="MerchHier_pub_1"  name="MerchHier Publisher, channel 1" state="running"
/><adapter id="UDAs_pub_1"  name="UDAs Publisher, channel 1" state="running"
/><adapter id="Order_pub_1"  name="Order Publisher, channel 1" state="running"
/><adapter id="Items_pub_1"  name="Items Publisher, channel 1" state="running"
/><adapter id="DiffGrp_pub_1"  name="DiffGrp Publisher, channel 1" state="running"
/><adapter id="Item
Loc_pub_1" name="ItemLoc Publisher, channel 1" state="running" /><adapter
id="Partner_pub_1" name="Partner Publisher, channel 1" state="running" /><adapter
id="Diffs_pub_1"  name="Diffs Publisher, channel 1" state="running" /><adapter
id="WOIn_pub_1"  name="WOIn Publisher, channel 1" state="running" /><adapter
id="Stores_pub_1"  name="Stores Publisher, channel 1" state="running" /></type>