| Oracle® Retail Integration Bus Implementation Guide Release 13.0.3 |
|
 Previous |
The "customization" of an Oracle Retail application often drives requirements to customize or extend the messages that flow among the Oracle Retail applications, or to create new message flows to support new business logic.
This document discusses the customization/extension approaches and best practices from an Oracle Retail Integration Bus (RIB) perspective for extending base messages, and for creating new messages and adapters. These are complex topics and should be performed with great care to avoid making future generally available (GA) releases difficult or impossible to accept.
Retailers often modify retail software either in-house or through third party system integrators. The customization and extension of Oracle Retail base products and messages are not supported by Oracle Retail, including My Oracle Support. This document aims to mitigate the risks of unsupported customization by providing guidance and references on how to attempt to customize safely and effectively. The tools and approaches described in this document are complex and require a high level of skill and knowledge of the product. Any issues that may arise with custom flows, custom APIs, or customized message families are the responsibility of the customer and not Oracle Retail.
Customization requires a number of considerations and planning steps. Planning helps prevent reinstallation and rearchitecture of the RIB due to operational or performance problems.
A functional RIB environment without customizations.
Familiarity with core RIB concepts, components, and architecture, including an understanding of all the following:
Oracle database triggers, RIB adapters, RIB Message envelope, RIB message payloads, and the functionality of GETNXT () and CONSUME () stored procedures.
The integration message flow paths.
The RIB life cycle.
The physical and logical requirements and limitations of the RIB components.
RIB operational considerations.
The tools used in the customization and extension of the RIB are documented separately. The primary tools are the Oracle Retail Functional Artifact Generator and the rib-app-builder tools.
Always keep an environment with a base version release to reproduce any base version issues. Only GA base code and messages are supported.
Always take a backup of the files being modified during the customization to allow for reversal of the changes.
As often as possible, use RIB tools such as RDMT, RIHA, and "Stubby" to test the customized changes.
Never modify the existing base flows in rib-integration-flows.xml. Modification can cause errors in functionality that are difficult to detect. Also, modifications made to base flows do not carry over to new releases, nor are they retained when defect fixes are applied to base code and objects.
When customizing or extending RIB messages or flows, all publishing and subscribing applications that participate in the flow must be considered.
In scenarios where payload customization or the addition of new message type for a particular message family is planned, and the flow contains a TAFR, the following additional rules apply:
TAFRs that do not examine RIB message types or payloads do not require modification.
For TAFRs that examine message types or payloads for filtering or transformation purposes, the TAFR implemention code must be changed. If this code is not changed, the messages will fail and land in RIB Error Hospital tables.
In the RIB, all messages are categorized by "message family" and "message type." A message family is specific to one or more Business Objects. It defines all publishable events occuring on the Business Objects.
The message type classifies a specific event. For example, the Orders message family is for messages about purchase orders, and the Vendor message family is for supplier or vendor information.
Typically, a message family includes at least one Create, Mod, and Delete operation.
To add a new message to an existing message family, the simplest approach is to add a new message type. The first step is to determine and create the payload for the new message type. The message payload must be created following the guideline and packaging rule for RIB messages.
Once the desired payload is ready, follow the instructions in the following sections, depending on the type of applications in the message family and in the message flow.
The new message type created for an already existing or new message family must be added in the rib-<app>-plsql-api.xml of the subscribing PL/SQL retail application.
|
Note: No configuration changes are needed in rib-<plsql app> whenever PL/SQL applications publish a new message type to which no PL/SQL applications subscribe. |
The following illustration indicates the files that must be changed inside the RIB infrastructure during the addition of new message type when a PL/SQL application is involved in the message flow.
To add a message type for message flows involving PL/SQL applications, complete the following steps.
Add the new message type in rib-<app>-plsql-api.xml, where app = rms or rwms in the <RIB_HOME>/application-assembly-home/rib-<app> directory.
For example, to add the new message type, "DiffGrpFooCre," for the DiffGrp message family that is subscribed by RWMS, add the message type under the <adaptorClassDef name="DiffGrp_sub"> of rib-rwms-plsql-api.xml in the <RIB_HOME>/application-assembly-home/rib-rwms as shown below.
cd <RIB_HOME>/application-assembly-home/rib-rwms
vi rib-rwms-plsql-api.xml
<adaptorClassDef name="DiffGrp_sub">
<class>com.retek.rib.collab.general.OracleObjectSubscriberComponentImpl</class>
<messageFamily name="DiffGrp">
<storedProc>
<signature>{call RDMSUB_DIFFGRP.CONSUME(?,?,?,?,?)}</signature>
<useFacilityType>true</useFacilityType>
</storedProc>
<messageType name="DIFFGRPDEL">
<oracleObject>RIB_DiffGrpRef_REC</oracleObject>
</messageType>
<messageType name="DIFFGRPDTLCRE">
<oracleObject>RIB_DiffGrpDtlDesc_REC</oracleObject>
</messageType>
<messageType name="DIFFGRPDTLDEL">
<oracleObject>RIB_DiffGrpDtlRef_REC</oracleObject>
</messageType>
<messageType name="DIFFGRPHDRCRE">
<oracleObject>RIB_DiffGrpHdrDesc_REC</oracleObject>
</messageType>
<messageType name="DIFFGRPDTLMOD">
<oracleObject>RIB_DiffGrpDtlDesc_REC</oracleObject>
</messageType>
<messageType name="DIFFGRPHDRMOD">
<oracleObject>RIB_DiffGrpHdrDesc_REC</oracleObject>
</messageType>
<messageType name="DIFFGRPFOOCRE">
<oracleObject>RIB_DiffGrpHdrDesc_REC</oracleObject>
</messageType>
</messageFamily>
</adaptorClassDef>
|
Note: Creating a temporary working directory, "customization-workarea," under <RIB_HOME>/tools-home is recommended. This directory can be used when performing customization related tasks. |
Edit the payload.properties file in the ./conf directory of the Artifact Generator tool installation. The payload.properties contains the new payload message definitions. The format of the definition is as follows:
RIBFAMILY.TYPE=IMPLEMENTATION CLASS NAME cd conf vi payload.properties (make changes)
For example, to add the new message type, "DiffGrpFooCre," for th DiffGrp message family, the modification to payload.properties is as follows:
DIFFGRP.DIFFGRPFOOCRE= com.retek.rib.binding.payload.DiffGrpHdrDesc
In this case, DiffGrpFooCre calls the implementation class, DiffGrpHdrDesc.
|
Note: For the maximum supported length of the message type, see the RibMessages.xsd in the rib-func-artifact.war. |
|
Note: If a TAFR is involved in the flow, the appropriate changes must be made to the TAFR to handle the new message types. |
Run the Artifact Generator to generate various functional artifacts.
$GROOVY_HOME/bin/groovy GenArtifacts.groovy
Each generated artifact is in the appropriate ./output*/dist folder, including:
rib-public-payload-database-object-types.zip
rib-public-payload-java-beans.jar
retail-public-bo-java-beans.jar
rib-public-payload-xml-samples.zip
Copy the newly generated artifact rib-public-payload-java-beans.jar from the appropriate ./output*/dist folder to <RIB_HOME>/application-assembly-home/rib-func-artifacts/ directory.
Run the rib-app-compiler.sh script from <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and prepare it for deployment.
cd <RIB_HOME>/application-assembly-home/bin
sh rib-app-compiler.sh
Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows.
cd <RIB_HOME>/deployment-home/bin
sh rib-app-deployer.sh -deploy-rib-func-artifact-war
This step deploys the rib-func-artifact.war.
sh rib-app-deployer.sh -deploy-rib-app-ear rib-<app>
The rib-<app> is deployed to the Java EE container. Repeat this step for each rib-<app> in the integration environment.
|
Note: The <app> value must be rms or rwms. |
The following illustration indicates the files that must be changed inside the RIB infrastructure during the addition of new message type when a Java EE application is involved in the message flow.
To add a message type for message flows involving Java EE applications, complete the following steps.
|
Note: Creating a temporary working directory, "customization-workarea," under <RIB_HOME>/tools-home is recommended. This directory can be used when performing customization related tasks. |
Edit the payload.properties file in the ./conf directory of the Oracle Retail Artifact Generator tool installation. The payload.properties contains the new payload message definitions. The format of the definition is as follows:
RIBFAMILY.TYPE=IMPLEMENTATION CLASS NAME
cd conf vi payload.properties (make changes)
For example, to add the new message type, "FooDeptCre," under the Merchhier message family to call the implementation class, MrchHrDeptDesc, the file is modified as follows:
MERCHHIER.FOODEPTCRE= com.retek.rib.binding.payload.MrchHrDeptDesc
|
Note: For the maximum supported length of the message type, see the RibMessages.xsd in the rib-func-artifact.war. |
|
Note: If a TAFR is involved in the flow, the appropriate changes must be made to the TAFR to handle the new message types. |
Run the Artifact Generator to generate various functional artifacts.
$GROOVY_HOME/bin/groovy
GenArtifacts.groovy
Each generated artifact is in the appropriate ./output*/dist folder, including
rib-public-payload-database-object-types.zip
rib-public-payload-java-beans.jar
retail-public-bo-java-beans.jar
rib-public-payload-xml-samples.zip
Copy the newly generated artifacts (listed above) from the appropriate ./output*/dist folders to the <RIB_HOME>/application-assembly-home/rib-func-artifacts/ directory.
Run the rib-app-compiler.sh script from <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and make it ready for deployment.
cd <RIB_HOME>/application-assembly-home/bin
sh rib-app-compiler.sh
Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows.
cd <RIB_HOME>/deployment-home/binsh rib-app-deployer.sh -deploy-rib-func-artifact-war
This step deploys the rib-func-artifact.war.
sh rib-app-deployer.sh -deploy-rib-app-ear rib-<app>
The rib-<app> is deployed. Repeat this step for each rib-<app> applicable to the integration environment.
|
Note: The <app> value must be rms or rwms. |
|
Note: To verify the addition of a new message type for a message family, see "Verifying the New Message Type." |
In the RIB, all messages are categorized by message family and message type. One option for customizing the RIB is to create a new message family with a new publishing adapter and a new subscribing adapter.
When creating a new message family, consider the following:
If the RIB a family also corresponds to a topic, it is recommended that the customization also include the creation of a new topic for that family.
A publishing adapter cannot publish to more than one JMS topic.
A subscribing adapter cannot subscribe to more than one JMS topic.
The first custom message flow must start with 901, with each subsequent custom messgae flow ID increasing by one from 901. For example, 901, 902, 903, and so on.
Each customized message flow ID should be unique and must follow the sequence.
A new message family requires new (or custom) Orace Retail application side APIs. Each API should be written, installed and tested independently, and then connected to the custom message family flows.
The following illustration indicates the files that require changes during the addition of new message family inside the RIB infrastructure.
To add a new message family, complete the following steps.
Create a temporary working directory, "customization-workarea," under <RIB_HOME>/tools-home to perform any customization related tasks.
Copy the rib-func-artifact.war in <RIB_HOME>/application-assembly-home/rib-func-artifacts/ directory into <RIB_HOME>/tools-home/ customization-workarea/ directory.
cd <RIB_HOME>/application-assembly-home/rib-func-artifacts cp rib-func-artifact.war <RIB_HOME>/tools-home/customization-workarea
Extract the rib-integration-flows.xml from the copied rib-func-artifact.war which needs to be modified.
cd <RIB_HOME>/tools-home/customization-workarea jar -xvf rib-func-artifact.war integration/rib-integration-flows.xml
Define the entire flow for the particular message family in rib-integration-flows.xml in /integration/ directory of <RIB_HOME>/tools-home/ customization-workarea.
A new custom message flow should always begin with <message-flow id="901">. Each customized message flow ID should be unique and must follow the sequence. Adding a new customized message flow with a message flow ID between 1 and 900 is not recommended, as this range is reserved for adding base flows in higher versions of RIB.
For example, when adding a new message family, "Foo," that flows from RMS to RWMS, the flow is defined in rib-integration-flows.xml as follows:
<message-flow id="901">
<node id="rib-rms.Foo_pub" app-name="rib-rms"
adapter-class-def="Foo_pub" type="DbToJms">
<in-db>default</in-db>
<out-topic>etFooFromRMS</out-topic>
</node>
<node id=" rib-rwms.Foo_sub" app-name=" rib-rwms"
adapter-class-def="Foo_sub" type="JmsToDb">
<in-topic>etFooFromRMS</in-topic>
<out-db>default</out-db>
</node>
</message-flow>
The convention is as follows:
node id = rib-<app>.<family>_pub or = rib-<app>.<family>_sub or could be external-system.<family>_pub or external-system.<family>_sub
app-name = rib-<app>. This is the application name. The <app> value is one of the following: rms, rwms, sim, aip, rpm, tafr, or external-system
adapter-class-def = <family>_pub or <family>_sub
type = DbToJms or JmsToDb
<in-db> is the source of the message is a database.
<out-db> is the destination of the message is a database
<out-topic> is the topic name to which the message would be published
<in-topic> is the topic name from which the message would be consumed.
Replace the previous existing rib-integration-flows.xml with the above changed rib-integration-flows.xml to the /integration/ directory of rib-func-artifact.war in the <RIB_HOME>/tools-home/customization-workarea/ directory and generate the rib-func-artifact.war as follows.
cd <RIB_HOME>/tools-home/customization-workarea jar -uvf rib-func-artifact.war integration/rib-integration-flows.xml
Create a new publishing adapter, subscribing adapter and TAFR adapter (if necessary), depending on the requirement for the new message family.
Create the message famly XSD.
The newly created XSD should conform to the Meta schema, IntegrationXmlMetaSchema.xsd. The artifact generator tools check the validity of the schema before generating any artifacts. If the schema is not compliant with the IntegrationXmlMetaSchema, the artifact generator fails. The file is in the conf directory of the Artifact Generator tool installation program.
Create a new message type.
Edit the payload.properties file in /conf directory of the Artifact Generator tool installation program. The payload.properties contains the new payload message definitions. The format of the definition is
RIBFAMILY.TYPE=IMPLEMENTATION CLASS NAME cd conf vi payload.properties (make changes)
For example, when adding a new message type, "FooCre," for the Foo message family that calls the implementation class, FooDesc, the payload.properties file is modified as follows:
FOO.FOOCRE= com.retek.rib.binding.payload.FooDesc
Run the Artifact Generator to generate various functional artifacts
$GROOVY_HOME/bin/groovy
GenArtifacts.groovy
Each generated artifact is in the appropriate ./output*/dist folder, including:
rib-public-payload-database-object-types.zip
rib-public-payload-java-beans.jar
retail-public-bo-java-beans.jar
rib-public-payload-xml-samples.zip
Copy the newly generated artifacts (listed above) from the appropriate ./output*/dist folders to the <RIB_HOME>/application-assembly-home/rib-func-artifacts/ directory.
New entries may be needed in the RIB_SETTINGS of the RMS application database to reference the new Message Family, only if the RMS application is in scope.
Run the rib-app-builder deployer: Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows to create the new topic (etFooFromRMS) in our flow. (The step to prepare JMS is not destructive, so even if it is run again it would remove all the topics and recreate them.)
cd <RIB_HOME>/deployment-home/bin
sh rib-app-deployer.sh -prepare-jms
Run the rib-app-builder compiler: Run the rib-app-compiler.sh script from <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and make it ready for deployment.
cd <RIB_HOME>/application-assembly-home/bin
sh rib-app-compiler.sh
Run the rib-app-builder deployer: Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows.
cd <RIB_HOME>/deployment-home/bin
sh rib-app-deployer.sh -deploy-rib-func-artifact-war
This deploys the rib-func-artifact.war.
sh rib-app-deployer.sh -deploy-rib-app-ear rib-<app>
The rib-<app> is deployed. Repeat this step for each rib-<app> that is in scope for this integration environment.
|
Note: The <app> value must be rms, rwms, tafr, sim, aip, or rpm. |
A RIB Adapter is a component that coordinates business event (message) generation and processing with the respective Oracle Retail application interface. Each adapter in the RIB is created to handle a specific functional interface.
When adding a custom publishing, subscribing or TAFR adapter, it is necessary to add or modify the message flows to which you are adding a custom adapter in the rib-integration-flows.xml. You also must update the rib-func-artifact.war and deploy the updated rib-func-artifact.war.
For example, when adding a new publisher, "Foo_pub," which publishes a message for the message family, Foo, that flows from RMS to RWMS, the flow in rib-integration-flows.xml is defined as follows:
<message-flow id="901">
<node id="rib-rms.Foo_pub" app-name="rib-rms"
adapter-class-def="Foo_pub" type="DbToJms">
<in-db>default</in-db>
<out-topic>etFooFromRMS</out-topic>
</node>
<node id=" rib-rwms.Foo_sub" app-name=" rib-rwms"
adapter-class-def="Foo_sub" type="JmsToDb">
<in-topic>etFooFromRMS</in-topic>
<out-db>default</out-db>
</node>
</message-flow>
|
Note: Before adding the flow above to the rib-integration-flows.xml flow, it is recommended that a temporary working directory ("customization-workarea" under <RIB_HOME>/tools-home) be created. This directory can be used for performing any customization related tasks. |
To add the flow to the rib-integration-flows.xml file, complete the following steps:
Copy the rib-func-artifact.war from the <RIB_HOME>/ application-assembly-home/rib-func-artifacts to <RIB_HOME>/tools-home/customization-workarea/ directory.
cd <RIB_HOME>/application-assembly-home/rib-func-artifacts cp rib-func-artifact.war <RIB_HOME>/tools-home/customization-workarea
Extract the rib-integration-flows.xml requiring modification from the copied rib-func-artifact.war as follows:
jar -xvf rib-func-artifact.war integration/rib-integration-flows.xml
Add the flow above to the rib-integration-flows.xml.
Update the rib-func-artifact.war with the modified rib-integration-flows.xml.
jar -uvf rib-func-artifact.war integration/rib-integration-flows.xml
Copy the rib-func-artifact.war from the <RIB_HOME>/tools-home/customization-workarea to <RIB_HOME>/application-assembly-home/rib-func-artifacts/ directory.
cd <RIB_HOME>/tools-home/customization-workarea cp rib-func-artifact.war <RIB_HOME>/application-assembly-home/rib-func-artifacts
Run the rib-app-builder compiler: Run the rib-app-compiler.sh script from <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and make it ready for deployment.
cd <RIB_HOME>/application-assembly-home/bin
sh rib-app-compiler.sh
Run the rib-app-builder deployer: Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows.
cd <RIB_HOME>/deployment-home/bin
sh rib-app-deployer.sh -deploy-rib-func-artifact-war
The rib-func-artifact.war is deployed.
The illustraton below indicates the files that require changes inside the RIB infrastructure for the addition of a new publishing adapter for a PL/SQL application.
Identify the flow to which the new adapter in being added.
Define the name of the publishing adapter. It should always follow the naming convention, RIBFAMILY_pub_ADAPTER INSTANCE NO.
Define the particular publishing adapter in rib-<app>-adapters.xml in <RIB_HOME>/application-assembly-home/rib-<app>, where <app> refers to either RMS or RWMS. The customer also must mention a custom attribute equal to "true" whenever a new customized publishing adapter is added.
For example, a new publishing adapter, "Foo_pub_1," for the Foo message family is defined in rib-<app>-adapters.xml as follows:
<timer-driven id="Foo_pub_1" initialState="running" timeDelay="10" custom="true">
<timer-task>
<class name="com.retek.rib.app.getnext.impl.GetNextTimerTaskImpl"/>
<property name="maxChannelNumber" value="1" />
</timer-task>
</timer-driven>
Define the particular publishing adapter in rib-<app>-adapters-resources.properties in <RIB_HOME>/application-assembly-home/rib-<app>, where <app> refers to either RMS or RWMS.
Foo_pub_1.name=Foo Publisher, channel 1 Foo_pub_1.desc=Publisher for the Foo family through channel 1.
Define the particular publishing adapter in rib-<app>-plsql-api.xml in <RIB_HOME>/application-assembly-home/rib-<app> where <app> refers to either RMS or RWMS as in below example.
|
Note: The signature of the stored procedure should come from the corresponding PL/SQL applications. |
<adaptorClassDef name="Foo_pub">
<class>com.retek.rib.collab.general.OracleObjectPublisherComponentImpl</class>
<messageFamily name="Foo">
<storedProc>
<signature>{call RMSMFM_FOO.GETNXT(?,?,?,?,?,?,?,?)}</signature>
</storedProc>
</messageFamily>
</adaptorClassDef>
Make the required changes to the rib-integration-flows.xml. See Adding the Custom Adapter to the rib-integration-flows.xml File.
Run the rib-app-builder compiler: Run the rib-app-compiler.sh script from <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and make it ready for deployment.
cd <RIB_HOME>/application-assembly-home/bin
sh rib-app-compiler.sh
Run the rib-app-builder deployer - Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows.
cd <RIB_HOME>/deployment-home/bin
sh rib-app-deployer.sh -deploy-rib-app-ear rib-<app>
The <app> is deployed.
The following illustration indicates the files that require changes inside the RIB infrastructure during the addition of a new publishing adapter for a Java EE application.
Identify the flow to which the new adapter in being added.
Define the name of the publishing adapter. It should always follow the naming convention, RIBFAMILY_pub_ADAPTER INSTANCE NO.
Define the particular publishing adapter in rib-<app>-adapters.xml in <RIB_HOME>/application-assembly-home/rib-<app>, where <app> refers to RPM, SIM, or AIP. The customer also must mention a custom attribute equal to "true" whenever a new customized publishing adapter is added.
For example, a new publishing adapter, "Foo_pub_1," for the Foo message family is defined in rib-<app>-adapters.xml as follows.
<request-driven id=" Foo_pub_1" initialState="notConfigurable" custom="true" />
Define the particular publishing adapter in rib-<app>-adapters-resources.properties in <RIB_HOME>/application-assembly-home/rib-<app>, where <app> refers to RPM, SIM, or AIP.
Foo_pub_1.name=Foo Publisher, channel 1
Foo_pub_1.desc=Publisher for the Foo family through channel 1.
Make the required changes to the rib-integration-flows.xml. See Adding the Custom Adapter to the rib-integration-flows.xml File.
Run the rib-app-builder compiler: Run the rib-app-compiler.sh script from <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and make it ready for deployment.
cd <RIB_HOME>/application-assembly-home/bin
sh rib-app-compiler.sh
Run the rib-app-builder deployer: Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows.
cd <RIB_HOME>/deployment-home/bin
sh rib-app-deployer.sh -deploy-rib-app-ear rib-<app>
The <app> is deployed.
The following illustration indicates the files that require changes inside the RIB infrastructure during the addition of a new subscribing adapter for PL/SQL applications.
To add a new subscribing adapter for a PL/SQL application, complete the following steps:
Identify the flow to which the new adapter in being added.
Define the name of the subscribing adapter. It should always follow the naming convention, RIBFAMILY_sub_ADAPTER INSTANCE NO.
Define the particular subscribing adapter in rib-<app>-adapters.xml in <RIB_HOME>/application-assembly-home/rib-<app>, where <app> refers to either RMS or RWMS. The customer also must mention a custom attribute equal to "true" whenever a new customized subscribing adapter is added.
For example, a new subscribing adapter, "Foo_sub_1," for the Foo message family, is defined in rib-<app>-adapters.xml as follows:
<message-driven id="Foo_sub_1" initialState="running" custom="true"/>
Define the particular subscribing adapter in rib-<app>-adapters-resources.properties in <RIB_HOME>/application-assembly-home/rib-<app>, where <app> refers to either RMS or RWMS.
Foo_sub_1.name= Foo Subscriber, channel 1
Foo_sub_1.desc=Subscriber for the Foo family through channel 1.
Define the particular subscribing adapter in rib-<app>-plsql-api.xml in <RIB_HOME>/application-assembly-home/rib-<app> where <app> refers to either RMS or RWMS as shown below.
|
Note: The signature of the stored procedure should come from the corresponding PL/SQL applications. |
<adaptorClassDef name="Foo_sub">
<class>com.retek.rib.collab.general.OracleObjectSubscriberComponentImpl</class>
<messageFamily name="Foo">
<storedProc>
<signature>{callRMSSUB_FOO.CONSUME(?,?,?,?)}</signature>
</storedProc>
<messageType name=" FOOCRE">
<oracleObject>RIB_FooDesc_REC</oracleObject>
</messageType>
<messageType name=" FooMOD">
<oracleObject>RIB_FooDesc_REC</oracleObject>
</messageType>
<messageType name=" FooDEL">
<oracleObject>RIB_FooRef_REC</oracleObject>
</messageType>
</messageFamily>
</adaptorClassDef>
Make the necessary changes to the rib-integration-flows.xml. See Adding the Custom Adapter to the rib-integration-flows.xml File.
Run the rib-app-builder compiler: Run the rib-app-compiler.sh script from the <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and make it ready for deployment.
> cd <RIB_HOME>/application-assembly-home/bin>
sh rib-app-compiler.sh
Run the rib-app-builder deployer: Run the rib-app-deployer.sh script from the <RIB_HOME>/deployment-home/bin directory as follows.
> cd <RIB_HOME>/deployment-home/bin>
sh rib-app-deployer.sh -deploy-rib-app-ear rib-<app>
The <app> is deployed.
The following illustration indicates the files that require changes inside the RIB infrastructure during the addition of a new subscribing adapter for a Java EE application.
To add a new subscribing adapter for a Java EE application, complete the following steps:
Identify the flow to which the new adapter in being added.
Define the name of the subscribing adapter. It should always follow the naming convention, RIBFAMILY_sub_ADAPTER INSTANCE NO.
Define the particular subscribing adapter in rib-<app>-adapters.xml in <RIB_HOME>/application-assembly-home/rib-<app>, where <app> refers to SIM or AIP. The customer also must mention a custom attribute equal to "true" whenever a new customized subscribing adapter is added.
For example, a new subscribing adapter, "Foo_pub_1" for the Foo message family is defined in rib-<app>-adapters.xml as follows:
<message-driven id="Foo_sub_1" initialState="running" custom="true" />
Define the particular subscribing adapter in rib-<app>-adapters-resources.properties in the <RIB_HOME>/application-assembly-home/rib-<app>, where <app> refers to SIM or AIP.
Foo_sub_1.name= Foo Subscriber, channel 1
Foo_sub_1.desc=Subscriber for the Foo family through channel 1.
Make the required changes to the rib-integration-flows.xml. See Adding the Custom Adapter to the rib-integration-flows.xml File.
Run the rib-app-builder compiler: Run the rib-app-compiler.sh script from the <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and make it ready for deployment.
> cd <RIB_HOME>/application-assembly-home/bin
> sh rib-app-compiler.sh
Run the rib-app-builder deployer: Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows.
> cd <RIB_HOME>/deployment-home/bin
> sh rib-app-deployer.sh -deploy-rib-app-ear rib-<app>
The <app> is deployed.
Transformation Address Filters/Router (TAFR) adapters transform message data and route messages. Multiple, message family specific TAFRs have already been implemented. Different TAFR adapters may be active on different message families or on the same message family, depending on the needs of an application. Not all message families require TAFRs.
The following topics should be considerd before writing a customized TAFR implementation for transformation, filtering or routing.
Transformation is handled in the TAFR implementation class. The following is an example of a TAFR that handles transformation.
public RibMessage transformRibMessage(RibMessage inMsg) throws TafrException {
// Transforms the incoming RibMessage into an outgoing RibMessage
RibMessage newMsg = transform(inMsg);
return newMsg; }
Filtering configuration involves updating the rib-tafr.properties file with the appropriate information. The property follows the usual properties naming convention (name=value). The property used for filtering is:
"for.<tafr name>_tafr.drop-messages-of-types"
Example:
for.ItemsToItemsISO
_tafr.drop-messages-of-types=ISCDimCre,ISCDimMod,ISCDimDel,ItemImageCre,ItemImageMod,
ItemImageDel,ItemUdaDateCre,ItemUdaDateMod,ItemUdaDateDel,ItemUdaFfCre,ItemUdaFfMod,
ItemUdaFfDel,ItemUdaLovCre,ItemUdaLovMod,ItemUdaLovDel
This property should be read as, "for ItemsToItemsISO tafr, drop these message types." A comma delimits the message types. If customization is required, rib-tafr.properties files must be updated for filtering to take place.
Routing is enabled by default for TAFRs; the RIB infrastructure handles this routing. If a TAFR requires routing based on message content, implementation classes override the following method.
public void routeRibMessage(RibMessage newMsg,MessageRouterIface router) throws TafrException {
router.addMessageForTopic(eventType, newMsg);
}
This section explains how to create a new TAFR adapter for a particular message family.
The following illustration indicates the files that require changes inside the RIB infrastructure during the addition of new TAFR adapter to a message family.
To add a new TAFR adapter, complete the following steps.
Identify the flow to which the new adapter in being added.
Define the name of the TAFR adapter. It should always follow the naming convention, RIBFAMILY_tafr_ADAPTER INSTANCE NO.
Define the corresponding implementation class name the TAFR needs to call.
Write the implementation class for the TAFR.
The default implementation of a TAFR implements the following interface in the RIB infrastructure.
package com.retek.rib.collab.tafr;
import com.retek.rib.domain.ribmessage.bo.RibMessage;
public interface TafrIface {
@return ribMessage that has been modified from the original one
public RibMessage transformRibMessage(RibMessage ribMsgIn) throws TafrException;
/**
* Filters message or messages contents accordingly. It is possible that
* this method could filter away the entire message thus returning null
* from this method.
*
* @param ribMsg
* @return ribMessage that may have been modified from the original one
* passed in or null.
*/
public RibMessage filterRibMessage(RibMessage ribMsgIn) throws TafrException;
/**
* Routes the message to the appropriate topic for publication.
*
* @param ribMsg RibMessage to be routed to the appropriate topic.
*/
public void routeRibMessage(RibMessage ribMsgIn, MessageRouterIface
router) throws TafrException;
public void processRibMessage(RibMessage ribMsgIn, MessageRouterIface
router) throws TafrException;
}
To implement a custom TAFR, complete the following steps:
Verify that the default implementation that comes with the RIB infrastructure is appropriate.
Create a rib-custom-tafr-business-impl.jar containing the customized implementation class for the specific message family and replace the same under <RIB_HOME>/application-assembly-home/rib-func-artifacts.
|
Note: See Metalink Note 837997.1, "How to Create a Custom TAFR Implementation." |
Define the particular TAFR adapter in rib-tafr-adapters.xml in <RIB_HOME>/application-assembly-home/rib-tafr. The customer must mention a custom attribute equal to "true" whenever a new customized TAFR adapter is added.
For example, when adding a new TAFR adapter, "Foo_tafr_1," for the Foo message family, the implementation class written is "SampleToSampleWH." The class is in com.retek.rib.collab.tafr.bo.impl, inside rib-custom-tafr-business-impl.jar. It should be defined in rib-tafr-adapters.xml as follows:
<message-driven id="Foo_tafr_1" initialState="running" tafr-business-
impl="com.retek.rib.collab.tafr.bo.impl.SampleToSampleWH"
custom="true" />
Define the particular TAFR adapter in rib-tafr-adapters-resources.properties in the <RIB_HOME>/application-assembly-home/rib-tafr.
Foo_tafr_1.name=Foo TAFR, channel 1
Foo_tafr_1.desc=TAFR for the Foo family through channel 1.
Make the required changes to the rib-integration-flows.xml. See "Adding the Custom Adapter to the rib-integration-flows.xml File."
Run the rib-app-builder compiler: Run the rib-app-compiler.sh script from the <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and make it ready for deployment.
cd <RIB_HOME>/application-assembly-home/bin
sh rib-app-compiler.sh
Run the rib-app-builder deployer: Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows.
cd <RIB_HOME>/deployment-home/bin
sh rib-app-deployer.sh -deploy-rib-app-ear rib-tafr
If there is a need to add more functionality to an existing TAFR than what is already provided, a class can be added to extend from the original TAFR class.
To change an existing TAFR adapter, complete the following steps:
Identify the TAFR to which more functionality should be added.
Define the corresponding implementation class name the TAFR needs to call. This class should extend from the original TAFR implementation class.
For example:
Additional functionality has to be added to the ASNOutToASNIn_tafr_1 TAFR with an implementation class of ASNOutToASNInLocFromRibBOImpl.
A new class should be written for the additional functionality that extends from ASNOutToASNInLocFromRibBOImpl.
If additional functionality is needed for the transformation of the message, call the transform method of the ASNOutToASNInLocFromRibBOImpl class and write your own code/logic.
|
Note: For information on how to write the implementation class., see the Metalink Note 837997.1, "How to Create a Custom TAFR Implementation." |
Write the implementation class for the TAFR.
Create a rib-custom-tafr-business-impl.jar containing the implementation class and replace the same under <RIB_HOME>/application-assembly-home/rib-func-artifacts.
|
Note: For more information on how to create the rib-custom-tafr-business-impl.jar, see the Metalink Note 837997.1, "How to Create a Custom TAFR Implementation." |
Replace the name of the implementation class with the new class name in the rib-tafr-adapters.xml as shown below. For example, if the name of the new class name is CustomASNOutToASNInLocFromRibBOImpl, the entry in tafr-adapters.xml should be:
<message-driven id="ASNOutToASNIn_tafr_1" initialState="running" tafr-business-impl=" com.retek.rib.collab.tafr.bo.impl. <br> CustomASNOutToASNInLocFromRibBOImpl " custom ="true"/>
Run the rib-app-builder compiler: Run the rib-app-compiler.sh script from the <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and make it ready for deployment.
cd <RIB_HOME>/application-assembly-home/bin
sh rib-app-compiler.sh
Run the rib-app-builder deployer: Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows.
cd <RIB_HOME>/deployment-home/bin
sh rib-app-deployer.sh -deploy-rib-app-ear rib-tafr
This section explains how to verify the various customizations using the RIB diagnostic and test tools, RDMT, the PL/SQL API simulator, and the Java EE API simulator.
These verification tests are described only from a RIB perspective and not as end-to-end testing. They should be considered only the first step in a process to move the customizations through the RIB life cycle.
The verification steps assume that these RIB tools have already been installed and are in working condition.
To verify the addition of a new message type under a message family from a RIB perspective, complete the following steps:
Log in to the RDMT main menu.
Select menu option 3, PUB/SUB/TAFR Utilities Submenu.
Publish a message using option 8, EJB Publish Utility.
Provide the new message type when prompted for the <type> parameter.
Use the sample message that was generated using the Artifact Generator tool after adding the new message type for the corresponding message family.
Check the corresponding adapter's RIBLOGS to be sure the message was published successfully. The logs are written to the path, <rib-application_instance_home>/<rib-app>/logs/<rib-app>.
For example, for /home/rib/product/10.1.3.3/OracleAS_1/j2ee/rib-rms-oc4j-instance/log/rib-rms, the RIBLOG file names are in the format, <adapter-instance-name>.rib.log.
Example:
Alloc_pub_1.rib.log
ASNIn_sub_1.rib.log
Enable the RIB Audit Logs for all the corresponding adapters involved in the message flow. The auditing feature logs the message as it passes through the RIB infrastructure. This helps the tracing of message content from publication to subscription, and all steps, such as a TAFR, in between.
|
Note: To enable RIB Audit logs, see "RIB Logging" in the Oracle Retail Integration Bus Operations Guide. |
Check the RIB audit logs for that particular message family adapter (publisher, subscriber, and TAFR, if involved) and verify whether the new message type added is part of the message header. Also ensure that the message passes successfully through all the adapters involved in the particular message flow.
Check whether the new message type was successfully consumed by the subscribing adapter.
To verify the addition of a new message family in the RIB, complete the following steps.
Once the RIB has been compiled and deployed (after adding new message family), check whether the new family adapters (publisher, subscriber, and TAFR, if involved) are visible through RIB Admin GUI.
The RIB admin GUI can be accessed via the URL as below.
http://<server>.us.oracle.com:<http-port>/rib-<app>-admin-gui/
Replace <server> with the name or IP address of the server in the environment where the rib-<app> deployed.
Replace <http-port> with the port number that the Oracle Application Server is listening on (for example, 7777).
Replace <app> with rms, tafr, rwms, sim, rpm, or aip.
Log in to the RDMT main menu.
Select menu option 3, PUB/SUB/TAFR Utilities Submenu.
Publish a message using option 8, EJB Publish Utility.
Provide the new message family when prompted for the <family> parameter.
Use the sample message created by the Artifact Generator tool for the corresponding new message family.
Check the corresponding adapter's RIBLOGS to be sure the message was published successfully. The logs are written to the path, <rib-application_instance_home>/<rib-app>/logs/<rib-app>.
For example, for /home/rib/product/10.1.3.3/OracleAS_1/j2ee/rib-rms-oc4j-instance/log/rib-rms, the RIBLOG file names are in the format, <adapter-instance-name>.rib.log.
Example:
Foo_pub_1.rib.log
Foo_sub_1.rib.log
Enable the RIB Audit Logs for all the corresponding adapters involved in the message flow. The auditing feature logs the message as it passes though the RIB infrastructure. This helps the tracing of message content from publication to subscription, and all steps, such as a TAFR, in between.
|
Note: To enable RIB Audit logs, see "RIB Logging" in the Oracle Retail Integration Bus Operations Guide. |
Check the RIB audit logs for the particular message family adapters (publisher, subscriber and TAFR, if involved) and verify whether the new message family added is part of the message header. Also ensure that the message passes successfully through all the adapters involved in the particular message flow.
To verify the addition of a new publishing adapter for PL/SQL for Java EE applications, complete the following steps.
Once the RIB has been compiled and deployed (after adding new publshing adapter), check whether the new publishing adapter is visible through RIB Admin GUI.
The RIB admin GUI can be accessed through the URL below.
http://<server>.us.oracle.com:<http-port>/rib-<app>-admin-gui/
Replace <server> with the name or IP address of the server in the environment where the rib-<app> is deployed.
Replace <http-port> with the port number that the Oracle Application Server is listening on (for example, 7777).
Replace <app> with rms, rwms, sim, rpm, or aip.
Log in to the RDMT main menu.
Select menu option 3, PUB/SUB/TAFR Utilities Submenu.
Publish a message using option 8, EJB Publish Utility.
Use the sample message created by the Artifact Generator tool for the corresponding message family.
Check the corresponding publishing adapter's RIBLOGS to be sure the message was published successfully. The logs are written to the path, <rib-application_instance_home>/<rib-app>/logs/<rib-app>.
For example, for /home/rib/product/10.1.3.3/OracleAS_1/j2ee/rib-rms-oc4j-instance/log/rib-rms, the RIBLOG file names are in the format, <adapter-instance-name>.rib.log.
Example:
Foo_pub_1.rib.log
Enable the RIB Audit Logs for the corresponding publishing adapter involved in the message flow. The auditing feature logs the message as it passes though the RIB infrastructure. This helps the tracing of message content from publication to subscription.
|
Note: To enable RIB Audit logs, see the section "RIB Logging" in the Oracle Retail Integration Bus Operations Guide. |
Check the RIB audit logs for that particular message family's publishing adapter and verify whether the message content is displayed correctly as published. Also ensure that the message passes successfully through all the adapters involved in the particular message flow.
To verify the addition of a new subscribing TAFR adapter for PL/SQL and Java EE applications, complete the following steps:
Once the RIB has been compiled and deployed after adding new subscribing adapter, check whether the new subscribing adapter is visible through RIB Admin GUI.
The RIB admin GUI can be accessed through the URL below.
http://<server>.us.oracle.com:<http-port>/rib-<app>-admin-gui/
Replace <server> with the name or IP address of the server in the environment where the rib-<app> is deployed.
Replace <http-port> with the port number that the Oracle Application Server is listening on (for example, 7777).
Replace <app> with rms, rwms, sim, rpm, or aip.
Log in to the RDMT main menu.
Select menu option 3, PUB/SUB/TAFR Utilities Submenu.
Publish a message using option 1, Publish Msg Utility, to the topic from which the newly added subscriber has to subscribe.
Use the sample message created by the Artifact Generator tool for the corresponding message family.
Check the corresponding subscribing adapter's RIBLOGS to check if the message was subscribed from the topic successfully. The logs are written to the path, <rib-application_instance_home>/<rib-app>/logs/<rib-app>.
For example, for /home/rib/product/10.1.3.3/OracleAS_1/j2ee/rib-rms-oc4j-instance/log/rib-rms, the RIBLOG file names are in the format, <adapter-instance-name>.rib.log.
Example:
Foo_sub_1.rib.log
Enable the RIB Audit Logs for the corresponding subscribing adapter. The auditing feature logs the message as it passes though the RIB infrastructure. This helps the tracing of message content from publication to subscription.
|
Note: To enable RIB Audit logs, see "RIB Logging" in the Oracle Retail Integration Bus Operations Guide. |
Check the RIB audit logs for the particular message family's subscribing adapter and verify whether the message content is displayed correctly. Also ensure that the message is subscribed successfully by the subscribing adapter
To verify the addition of a new TAFR adapter, complete the following steps:
Once the RIB has been compiled and deployed after adding new TAFR adapter, check whether the new TAFR adapter is visible through RIB Admin GUI.
The RIB admin GUI can be accessed via the URL as below.
http://<server>.us.oracle.com:<http-port>/rib-tafr-admin-gui/
Replace <server> with the name or IP address of the server in the environment that has the rib-<app> deployed.
Replace <http-port> with the port number that the Oracle Application Server is listening on (for example, 7777).
Log in to the RDMT main menu.
Select menu option 3, PUB/SUB/TAFR Utilities Submenu.
Publish a message using option 1, Publish Msg Utility, to the topic from which the newly added subscriber has to subscribe.
Use the sample message created by the Artifact Generator tool for the corresponding message family.
Check the corresponding TAFR adapter's RIBLOGS to be sure the message was subscribed by the TAFR from the particular topic and published to the next destination topic successfully. The logs are written to the path, <rib-application_instance_home>/rib-tafr/logs/rib-tafr.
For example, for/home/rib/product/10.1.3.3/OracleAS_1/j2ee/rib-tafr-oc4j-instance/log/rib-tafr, the RIBLOG file names are in the format, <adapter-instance-name>.rib.log.
Example:
Foo_tafr_1.rib.log
Enable the RIB Audit Logs for the corresponding TAFR adapter. The auditing feature logs the message as it passes though the RIB infrastructure. This helps the tracing of message content from publication to subscription.
|
Note: To enable RIB Audit logs, see "RIB Logging" in the Oracle Retail Integration Bus Operations Guide. |
Check the RIB audit logs for the particular message family's TAFR adapter and verify whether the message content is displayed correctly.
The customization of payloads gives a customer the ability to add/modify data which flows from one application to the other.
|
Note: The Artifact Generator tool must be installed before performing any payload customizations. See the Oracle Retail Integration Bus Operations Guide for information on the installation and usage of the Artifact Generator tool. |
Individuals performing the tasks for payload customization should be familiar with the Artifacts Generator tool and have an understanding of the following:
The importance of payloads and how they fit into the suite of Oracle Retail applications.
The impact that customizing a payload has on other applications.
The following is a list of recommendations for ensuring successful payload customization.
Always back up the files that will be modified during customization in case they need to be restored.
When payloads are customized, the changes applied must also be made on the application side.
During customization, only optional elements should be added. The addition of mandatory elements to payloads can result in increased maintenance efforts.
Names of elements in XSDs must not be Java key words.
To add of an optional element (simple type or complex type) to an existing message payload, complete the following steps:
Edit the desired payload XSDs in the ./input-xsd directory of the Artifact Generator tool installation. Add the optional simple or complex element to the particular message family XSD and, if necessary, define the type.
cd input-xsdvi ItemRef.xsd (make changes)
For example, to add an optional simple element, "attr1," and a complex element, "ItemDtlRef," to ItemRef.xsd, the modification to ItemRef.xsd is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified"
targetNamespace="http://www.oracle.com/retail/integration/payload/ItemRef"
xmlns="http://www.oracle.com/retail/integration/payload/ItemRef"
xmlns:retailDoc="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ItemDtlRef">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="clearance_id" type="number10">
</xs:element>
<xs:element maxOccurs="unbounded" name="item" type="varchar225">
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ItemRef">
<xs:complexType>
<xs:sequence>
<xs:element name="item" type="varchar225"/>
<xs:element name="attr1" type="number10" minOccurs="0"/>
<xs:element maxOccurs="unbounded" minOccurs="0" ref="ItemDtlRef"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="varchar225">
<xs:restriction base="xs:string">
<xs:maxLength value="25"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="number10">
<xs:restriction base="xs:long">
<xs:totalDigits value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Run the Artifact Generator to generate various functional artifacts.
$GROOVY_HOME/bin/groovy GenArtifacts.groovy
Each generated artifact is in the appropriate ./output*/dist folder, including:
rib-public-payload-database-object-types.zip
rib-public-payload-java-beans.jar
retail-public-bo-java-beans.jar
rib-public-payload-xml-samples.zip
|
Note: See the Oracle Retail Integration Bus Operations Guide for information on how to use the Artifact Generator tool to generate artifacts. |
Copy the newly generated artifacts (listed above) from the appropriate ./output*/dist folders to the <RIB_HOME>/application-assembly-home/rib-func-artifacts/ directory.
The artifact generator tool cannot be used to generate the rib-func-artifact.war. The file must be created manually as follows:
Copy the rib-func-artifact.war from <RIB_HOME>/ application-assembly-home/rib-func-artifacts to <RIB_HOME>/tools-home/customization-workarea/ directory.
cd <RIB_HOME>/application-assembly-home/rib-func-artifacts cp rib-func-artifact.war <RIB_HOME>/tools-home/customization-workarea
Extract only the XSD that must be modified from the copied rib-func-artifact.war, as shown below.
jar -xvf rib-func-artifact.war payload/xsd/ItemRef.xsd
Copy and replace the same modified payload XSD from ./input-xsd directory of the Artifact Generator tool installation program to the <RIB_HOME>/tools-home/customization-workarea/ payload/xsd directory .
cd ArtifactGeneratorInstallation_directory/input-xsd cp ItemRef.xsd <RIB_HOME>/tools-home/customization-workarea/payload/xsd
After replacing the existing ItemRef.xsd with the changed ItemRef.xsd to the /payload/xsd directory of rib-func-artifact.war in the <RIB_HOME>/tools-home/customization-workarea/ directory, generate the new rib-func-artifact.war as shown below.
cd <RIB_HOME>/tools-home/customization-workarea jar -uvf rib-func-artifact.war payload/xsd/ItemRef.xsd
Copy the generated rib-func-artifact.war from <RIB_HOME>/tools-home/customization-workarea to the <RIB_HOME>/application-assembly-home/rib-func-artifacts/ directory.
cd <RIB_HOME>/tools-home/customization-workarea cp rib-func-artifact.war <RIB_HOME>/application-assembly-home/rib-func-artifacts
Run the rib-app-builder compiler: Run the rib-app-compiler.sh script from the <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and make it ready for deployment.
cd <RIB_HOME>/application-assembly-home/bin
sh rib-app-compiler.sh
|
Note: See the section, "rib-app-builder Tools," in the Oracle Retail Integration Bus Operations Guide. |
Run the rib-app-builder deployer: Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows.
cd <RIB_HOME>/deployment-home/bin
sh rib-app-deployer.sh -deploy-rib-func-artifact-war
This step deploys the rib-func-artifact.war to the Java EE container.
sh rib-app-deployer.sh -deploy-rib-app-ear rib-<app>
The rib-<app> is deployed to the Java EE container. Repeat this step for each rib-<app> in scope for this integration environment.
|
Note: The <app> value must be rms, rwms, tafr, sim, aip, or rpm. |
The following steps must be completed to add a new XSD to a current set of payloads:
Create a new XSD which conforms to the MetaSchema ie IntegrationMetaSchema.xsd. The artifact generater tool checks the validity of the schema before generating any artifacts. The artifact generater will fail if the XSD is not compliant with the MetaSchema.
Drop the new XSD in here: ./input-xsd/ directory of the Artifact Generator tool installation.
For example, if you create a XSD called "Foo.xsd", place it under ./input-xsd/.
Run the Artifact Generator to generate various functional artifacts.
$GROOVY_HOME/bin/groovy GenArtifacts.groovy
Each generated artifact is in the appropriate ./output*/dist folder, including:
rib-public-payload-database-object-types.zip
rib-public-payload-java-beans.jar
retail-public-bo-java-beans.jar
rib-public-payload-xml-samples.zip
Copy the newly generated artifacts (listed above) from the appropriate ./output*/dist folders to the <RIB_HOME>/application-assembly-home/rib-func-artifacts/ directory.
|
Note: See the Oracle Retail Integration Bus Operations Guide for information on how to use the Artifact Generator tool to generate artifacts. |
The artifact generator tool cannot be used to generate the rib-func-artifact.war. The file must be created manually as follows:
Copy the rib-func-artifact.war from <RIB_HOME>/ application-assembly-home/rib-func-artifacts to the <RIB_HOME>/tools-home/customization-workarea/ directory.
cd <RIB_HOME>/application-assembly-home/rib-func-artifacts cp rib-func-artifact.war <RIB_HOME>/tools-home/customization-workarea
Copy the newly created XSD (Foo.xsd) to the /payload/xsd/ directory under <RIB_HOME>/tools-home/customization-workarea/ directory and update the rib-func-artifact.war.
cd <RIB_HOME>/tools-home/customization-workarea jar -uvf rib-func-artifact.war payload/xsd/Foo.xsd
Copy the generated rib-func-artifact.war from <RIB_HOME>/tools-home/customization-workarea to the <RIB_HOME>/application-assembly-home/rib-func-artifacts/ directory.
cd <RIB_HOME>/tools-home/customization-workarea cp rib-func-artifact.war <RIB_HOME>/application-assembly-home/rib-func-artifacts
Run the rib-app-builder compiler: Run the rib-app-compiler.sh script from <RIB_HOME>/application-assembly-home/bin directory to generate/assemble a rib-<app> and make it ready for deployment.
cd <RIB_HOME>/application-assembly-home/binsh rib-app-compiler.sh
Run the rib-app-builder deployer: Run the rib-app-deployer.sh script from <RIB_HOME>/deployment-home/bin directory as follows.
cd <RIB_HOME>/deployment-home/bin
sh rib-app-deployer.sh -deploy-rib-func-artifact-war
This deploys the rib-func-artifact.war to the Java EE container.
sh rib-app-deployer.sh -deploy-rib-app-ear rib-<app>
The rib-<app> is deployed to the Java EE container. Repeat this step for all rib-<app> that is in scope for this integration environment.
|
Note: The <app> value must be rms, rwms, tafr, sim, aip, or rpm. |
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|