Oracle® Retail Integration Bus Cloud Service Operations Guide Release 19.1.000 F31988-02 |
|
![]() Previous |
![]() Next |
The following graphic illustrates the names of the actual RIB files and shows their location in the deployment picture.
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.
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. |
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.
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>
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"/>
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>
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.
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.
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= Below are list of properties file that are updated for current release
|
drop-messages-of-types | Undesired message types can be filtered in RIB subscriber. This is configurable setting.
Steps to set the
|
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- |
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 |
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 |
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- |
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. |
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. |
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. |
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>
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.
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>
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>
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>
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>
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>
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.
This is a non editable file that describes the structure of the rib-<app>.ear and the resources it uses.
This is a non editable file that describes the service related configuration used by rib-<app> to identify the relevant service implementations.
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.
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.
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.
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.
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.
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-->
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 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><BannerDesc xmlns="http://www.oracle.com/retail/integration/payload/BannerDesc" xmlns:ribdate="http://www.oracle.com/retail/integration/payload/RIBDate"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="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"> <banner_id>1</banner_id> <banner_name>B&amp;M</banner_name></BannerDesc></messageData> <customData></customData><customFlag>F</customFlag> </ribMessage> </RibMessages>
The following are examples of other RIB management logs.
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).
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).
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>