1. Implementation Guide
  2. Integration Architecture

2 Integration Architecture

This chapter explains the different components that are used to make the whole integration work seamlessly.

Figure 2-1 Universal Service Mapper Architecture

Universal Service Mapper Architecture

The component that is used to do the mapping needed for this integration is referred to as the universal service mapper (USM). It has three major components:

  • Event Listener

  • Service Mapper Orchestrator

  • External Service Invocation and Service Provider

Event Listener

The Event Listener is a service which is open to receiving data from the application that is connected to it. For the integration covered in this document, the two applications are a RIB component called RIB-LGF and WMS Cloud. The applications have the following URL pattern set in their target for USM: http://<host>:<port>.

When the application sends data, the Event Listener internally calls the Abstract Service Mapper, which determines the family, message type and the operations from the message received by referring to the Service Definition JSON files. These files store the crucial data required for the communication of the participating applications, including the host URLs of the source and destination applications along with usernames and passwords, if applicable.

Service Map Orchestrator

The Abstract Service Mapper in turn calls the Service Map Orchestrator which decides what data is to be populated in the mapper templates. The orchestrator does the mapping, field by field, from the source application to destination application.

The actual mapping logic is contained in orchestration files. All fields are mapped using a one-to-one mapping. Fields not required by the destination application are simply dropped. If a field is not present in the source data, then it is mapped using a pre-determined default value or left as null if allowed.

Certain key-value pairs are also managed in the integration layer in order to maintain context between the applications. See Domain Value Maps (DVMs) for more information on this configuration.

Service Provider and External Services

The Service Map Orchestrator component calls the services hosted by the service providers (RIB-LGF or WMS Cloud) after the mapping operations are completed. The service provider consumes these REST service calls via USM. USM holds the information necessary for it to call these services in a file.

Templates

Templates files hold the actual mapping information and use an xml format. There are three different types of templates used:

  • Request Templates – used when the source application sends a message that has to be mapped to the destination application format.

  • Response Templates – the result of the mapping that has been performed on the source application.

  • Failure Templates – contain error codes and messages due to issues incurred in the mapping process, such as missing data or unexpected server events.

These templates are visible in the USM user interface to help manage errors that may occur in the integration.

Domain Value Maps (DVMs)

Domain Value Maps are tables that live in the integration layer that contain defaults and cross references used in the mapping between applications and assist in transforming the messages from one format to the other. There are two types of DVMs - static and dynamic. Static DVMs are used for foundational or seed data that doesn't often change. Dynamic DVMs are built during runtime and usually associated with transactional data, such as purchase orders.

For more information on all these concepts and the overall architecture, see the Oracle Retail Integration Cloud Service Universal Service Mapper User Guide.