4 Implementing RIB-EXT

RIB-EXT is an Oracle Retail Integration Application that provides necessary communication channel for external applications to publish and consume message from RIB's JMS on cloud and premise.

Note:

For more information on WDSL's, see the Oracle Retail Cloud Service Integration Guide and for information on plugable jar, see the Client Connector For Oracle Retail Integration Cloud Service 22.0.000 (Patch) available on My Oracle Support.

How to Send and Receive Messages to/from RIB System using SOAP API's

External Application as a Publisher (soap-app)

For external applications to publish to the RIB JMS on cloud, it needs to use a publishing webservice provided by rib-ext. The WSDL URL of publishing service is as follows:

http://<rib-ext-host>:<port>/ApplicationMessagePublishingServiceBean/ApplicationMessagePublishingService?wsdl

An external application can publish messages using the above webservice only when rib-ext is configured as a soap-app.

External Application as a Subscriber (soap-app)

For an external application to consume the message from the RIB's JMS on cloud, it has to host the Injector Service. External application can make use of pluggable jar to expose injector service.

Include rib-private-app-plugin jar in to the external application deployable file for example, ext-app.ear/lib.

Subscriber adapters in rib-ext makes a SOAP call to Injector service to send the message to the external application. The WSDL URL of injector service If pluggable jar is used, it will look like:

http://<external-app-host>:<port>/ApplicationMessageInjectorBean/InjectorService?wsdl

How to Send and Receive Messages to/from RIB System using ReSTful API's

External Application as a Publisher (rest-app)

For external applications to publish to the RIB JMS on cloud, it needs to use a publishing webservice provided by rib-ext. The following table contains the publisher ReST service endpoint (pattern) exposed by rib-ext for a client to hook to:

Table 4-1 APIs and Rest End Points

API	Rest End Point
Application WADL	http://<rib-ext-host>:<port>/rib-<app>-services-web/resources/application.wadl
Ping resource	http://<rib-ext-host>:<port>/rib-<app>-services-web/resources/publisher/ping
Publish resource	http://<rib-ext-host>:<port>/rib-<app>-services-web/resources/publisher/publish

An external application can publish messages using the above webservice only when rib-ext is configured as a rest-app.

Implement ReST Client to Call the Publisher Service

In order to publish messages to RIB via ReST service, a standard JAX-RS client API can be used. We provide a few helper libraries and payload jars (RBO contracts) to be used on the classpath of a client application. jars are packaged inside client connector pak for rib-ext.

The required libraries are:

application-message-publishing-service-consumer-22.0.000.jar
commons-logging-1.2.jar
rib-public-api-22.0.000.jar
retail-private-int-common-util-22.0.000.jar
retail-public-payload-java-beans-22.0.000.jar
retail-public-payload-java-beans-base-22.0.000.jar
retail-rest-service-common-util-22.0.000.jar
rib-private-common-22.0.000.jar

See Rest Publisher Pseudo Code for sample code.

External Application as a Subscriber (rest-app)

For an external application to consume the message from the RIB's JMS on cloud, it has to host the Injector Service.

Subscriber adapters in rib-ext makes a ReST call to injector service to send the message to the external application. The customer can choose to write their own implementation of injector service following the contract or can make use of the pluggable jar along with reference implementation provided in connector pack for rib-ext.

Example - The End Point of injector service will look similar to the following in case reference jar is used:

http://<external-app-host>:<port>/ rib-injector-services-web/resources/injector/inject

How to Implement Injector Service (CONSUME messages from RIB) using ReST (Contract)

Here is the Rest service contract detail which can be used for implementing rest inject services.

Keep the path as Injector/inject.
```
@Path("/injector")
```
Use POST for this service. As the input message object itself has identifier (message type- CRE/MOD) you do not need to use the PUT/PATCH. You can use message type to build the implementation logic.
```
@POST
@Path("/inject")
@Consumes({MediaType.APPLICATION_XML})
```

The input would be MediaType.APPLICATION_XML and the structure would be 'ApplicationMessage' object. (See Appendix A, "Sample Files" for detailed xsd).

<xs:element name="ApplicationMessage">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="family" type="string25"/>
      <xs:element name="type" type="string30"/>
      <xs:element name="businessObjectId" type="string255" minOccurs="0"/>
      <xs:element ref="ApplicationMessageRoutingInfo" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="payloadXml" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

Customer can utilize the payload.properties file for validation of message family and type. (See Appendix A, "Sample Files" for sample payload.properties)

Return type should be JSON, see below example:

String message = "{\"message\": \"Inject successful.\"}";
return Response.ok(message, MediaType.APPLICATION_JSON).build();

For exception response customer needs to follow the structure of exceptionVO.

public class ExceptionVo
{
    public String getStatus()
    {
        return status;
    }
    public void setStatus(String status)
    {
        this.status = status;
    }
    public String getMessage()
    {
        return message;
    }
    public void setMessage(String message)
    {
        this.message = message;
    }
    public String getStackTrace()
    {
        return stackTrace;
    }
    public void setStackTrace(String stackTrace)
    {
        this.stackTrace = stackTrace;
    }
    public int getStatusCode()
    {
        return statusCode;
    }
    public void setStatusCode(int statusCode)
    {
        this.statusCode = statusCode;
    }
    public ExceptionVo(int statusCode, String status, String message, String stackTrace)
    {
        this.statusCode = statusCode;
        this.status = status;
        this.message = message;
        this.stackTrace = stackTrace;
    }
    public ExceptionVo()
    {
    }
    public String toString()
    {
        return (new StringBuilder()).append("ExceptionVo{statusCode=").append(statusCode).append(", status=").append(status).append(", message=").append(message).append(", stackTrace=").append(stackTrace).append('}').toString();
    }
    int statusCode;
    String status;
    String message;
    String stackTrace;
}

See Appendix A, "Sample Files" (application.wadl, Resource file, Sample request/response etc.).

Note:

A Reference implementation for injector service is provided, See Reference Implementation of Injector Service Using Tomcat for details.

Error Handling

The RIB infrastructure provides a mechanism called RIB error hospital to handle and manage the error messages. When the publishing or subscription of a message fails in the rib-ext for some reason, it lands in error hospital with a reason code. The retry adapters in the rib-ext application are responsible for retrying the messages in error hospital.

Oracle RIB Hospital Administration (RIHA) is a Weblogic application that allows the management of messages in error hospital. Some of the RIHA operations include:

Viewing error messages
Editing error messages
Retrying error messages
Stopping error messages

For more information, see the Oracle Retail Integration Bus Hospital Administration Guide.