| Oracle® Retail Service Backbone Developers Guide 16.0 E80535-01 |
|
 Previous |
 Next |
Injector Service is a mechanism for external web services to subscribe data published in RIB topics. In the absence of this method, external applications will always have to subscribe directly to RIB JMS topics and parse the messages. With help of the injector service, RIB can now invoke external web services to send messages to those applications.
RSB has a service integration flow which is based on RIB injector service. The purpose of this service integration flow is to route messages from RIB-OMS application to RSB decorator services. This service integration flow is an OSB project and it is available in RsbServiceIntegrationFlowPak16.0.0ForRibOmsToRsbOmsRouting_eng_ga.zip PAK. The OSB jar packaged inside the PAK is RibOmsToRsbOmsRouting-ServicesIntegrationFlow.jar.
This OSB jar contains a Proxy Service which is based on Injector Service WSDL. The name of the proxy service is RibOmsToRsbOmsRoutingService. The WSDL contains an operation named as injectMessage(). This operation requires four parameters: message family, message type, business object ID and payload. When RIB-OMS application receives a message on one of its topics, it builds the request message with appropriate values for the parameters and invokes injectMessage() method of the RibOmsToRsbOmsRoutingService proxy service. Business Object Id is an optional parameter and it may be null but rest of the parameters are required.
Copy the RibOmsToRsbOmsRouting-ServicesIntegrationFlow.jar to RSB_WORK_AREA/service-integration-flows folder. The directory structure looks like this:
Now we need to import this jar in JDeveloper. To import the jar, select File > Import > Service Bus Resources.
Click Browse and select the jar file.
Click Next. It will show all the files available in the jar.
Click Finish. The jar is imported as an OSB project and the project structure looks like the following:
The following diagrams show the message flow in the proxy service of the routing project. The whole message flow does not fit in once screenshot, so the first picture shows message flow at a high-level; it shows all the pipelines that define the message flow.
The next screenshot is of the remaining part of the updateSoapRequest pipeline-pair where most of the message processing takes place.
When RibOmsToRsbOmsRoutingService proxy service receives the request XML, it executes the message flow. The sequence of activities in the flow is explained below:
The Message flow has a conditional branch, which checks for operation name in the SOAP request.
The first condition is to check if operation invoked is ping. If operation name is ping, then the proxy service does not need to do further processing, it just builds a success response for ping method and returns the response to the client.
If operation name is not ping, then the message goes to a Pipeline Pair which is named as updateSoapRequest. In request flow of that pipeline pair, these are the things that take place:
Find the message family from the request and assign to a variable.
Find the message type from the request and assign to a variable.
Execute an xquery to check if the message needs to be dropped, that is, the proxy service should do nothing and return an appropriate response to the client. So if the message is of drop type, then it skips rest of the pipeline and returns an appropriate response to the client. Table 5-1 shows the combination of message family and message type which are dropped by the proxy service.
If the message is not of drop type, then it extracts the payload from the request and saves it to a variable.
Execute an xquery to set namespace and operation name in the outgoing request for the target decorator service.
Build a new SOAP body with the payload that was stored in a variable.
The proxy service uses dynamic routing to route the request to target decorator service. The dynamic routing action is based on an xquery file. This xquery builds route message context which is used by dynamic routing to route to the appropriate service. The table 5-2 shows the mappings between message family, message type which are routed to decorator service URIs.
Message is routed to the proxy service of the target decorator project.
When the target decorator returns the response, then the response pipeline is executed. In the response pipeline, the response returned from decorator is logged. Finally a string with success response is returned to the proxy service client.
If an error occurs in the RibOmsToRsbOmsRoutingService message flow, then the Service Error handler pipeline is executed. In this pipeline, an XQuery is used to build appropriate fault message. The fault is returned to the client with failure status.
The following table contains the combination of Message Family and Message Type that are dropped by routing service:
| Message Family | Message Type |
|---|---|
| pendreturn | pendretcre |
| pendreturn | pendretmod |
| pendreturn | pendretdel |
| pendreturn | pendretdtlcre |
| pendreturn | pendretdtlmod |
| pendreturn | pendretdtldel |
| asnout | asnoutmod |
| receiving | appointcre |
| receiving | appointdel |
| receiving | receiptcre |
| receiving | receiptmod |
| receiving | appointdtlcre |
| receiving | appointdtldel |
| receiving | appointdtlmod |
| receiving | appointhdrmod |
The following table contains the list of decorator service URI to which messages with combination of Message Family, Message type are routed:
| Message Family | Message Type | Decorator Service URI |
|---|---|---|
| pendreturn | rtrnrcptnotify | oms-OrderReturn-AppServiceDecorator/ProxyService/OrderReturnAppServiceLocalProxy |
| pendreturn | rtrncomplete | oms-OrderReturn-AppServiceDecorator/ProxyService/OrderReturnAppServiceLocalProxy |
| sostatus | sostatuscre | oms-StockOrderStatus-AppServiceDecorator/ProxyService/StockOrderStatusAppServiceLocalProxy |
| asnout | asnoutcre | oms-AdvancedShipmentNotification-AppServiceDecorator/ProxyService/AdvancedShipmentNotificationAppServiceLocalProxy |
| fulfilordcfm | fulfilordcfmcre | oms-FulfillOrderConfirm-AppServiceDecorator/ProxyService/FulfillOrderConfirmAppServiceLocalProxy |
| fulfilordcfmcnc | fulfilordcfmcnccre | oms-FulfillOrderCancelConfirm-AppServiceDecorator/ProxyService/FulfillOrderCancelConfirmAppServiceLocalProxy |
| asnin | asnincre | oms-VendorShipmentNotification-AppServiceDecorator/ProxyService/VendorShipmentNotificationAppServiceLocalProxy |
| asnin | asninmod | oms-VendorShipmentNotification-AppServiceDecorator/ProxyService/VendorShipmentNotificationAppServiceLocalProxy |
| asnin | asnindel | oms-VendorShipmentNotification-AppServiceDecorator/ProxyService/VendorShipmentNotificationAppServiceLocalProxy |
| receiving | receiptordcre | oms-CustomerOrder-AppServiceDecorator/ProxyService/CustomerOrderAppServiceLocalProxy |
The table 5-2 contains the list of all decorator URIs services to which RibOmsToRsbOmsRoutingService routes the messages. It is also possible to add routing to a new decorator service by modifying XQuery files in the OSB project. This document covers only the RSB side of changes. For adding message flow for a new message family and message type from RIB, there are changes required in RIB side too. Please refer to RIB documents for changes in the RIB side. This document assumes that RIB-OMS application can invoke the RibOmsToRsbOmsRoutingService for a new message family and message type and now RibOmsToRsbOmsRoutingService needs to route those messages to the appropriate decorator. Follow the steps to achieve the same:
If the message needs to be just dropped by RibOmsToRsbOmsRoutingService and not to be processed further, the only change required in the project is to add the new message family and type in the isMessageOfDropType xquery file.
If the message need not be dropped and should be routed to a decorator, then there are no changes required in isMessageOfDropType file. In this case, open the buildRoutingContext xquery file. This xquery builds the path to the target decorator service.
For routing to a decorator service, the request message also needs to contain the operation name and namespace for the target service. To set new operation name and namespace in the request message, open the setNamespaceAndOperationInSoapBody xquery file and add appropriate code.
The changes to the three xquery files are all that is needed in OSB project. There is a properties file in rsb-home that also needs to be modified. This properties file is used by RSB builder tool to update RSB artifacts appropriately.
