3 USM Functional Architecture

Universal Service Mapper (USM) is a platform that allows you to define, map, configure and deploy projects that are required to maintain a seamless integration between two heterogeneous applications.

The application has two components, the User interface and the Engine.

USM User Interface

The user interface gives you the ability to do the following:

• Create and Manage:

  • Projects in USM

  • Service Mapper Files

  • Drivers

  • Configuration Files

• View:

  • App statistics

  • Metrics about the message flow

  • System Logs

USM Engine

The USM engine is the logic part of the system. It is where the data is received from one application, mapped to other data, and the mapped data is sent to other applications. Data is communicated through service calls.

USM hosts all the necessary web services required by the participating sender and receiver applications. USM has a configuration file that needs up-to-date service URLs for the participating applications.

USM also has the templates that contain the mapping information, the code that does the mapping, and also the configuration files that need to be configured to make the application work.

USM Project

A USM Project has the templates that contain the mapping information, the code that does the mapping, and the configuration files that need to be configured to make the application work.

There is one Project per integration. For example, there would be one Project integrating RMS with Oracle Warehouse Management Cloud Service.

There can be multiple Projects (integrations) hosted by one USM instance. For example, a single USM instance can host the integration between Oracle Warehouse Management and RMS, and an integration between Oracle Customer Management and Oracle ATG Web Commerce.

Oracle Retail creates the initial USM Projects for supported integrations and packages and ships them with the base product.

Modules

Each project in USM has a property named ”Modules”. The artifacts of this project are identified by the modules associated with the project. Each artifact having a prefix with a project module is associated with the project. EAch project can have a minimum of one module and a maximum of 4 modules.

Templates

Template files are the main files holding the actual mapping information used during a mapping. Templates associate different fields in different payloads with one another, mapping fields from one application format to another using the XML format.

There are three different types of templates being used to map data. These files are of the XML data descriptors. The three types are:

• Request Templates

• Response Templates

• Failure Templates

The templates are used to perform data mapping when the participating applications need to communicate with each other.

The Request templates are used when the participating source application sends a message with data that has to be mapped to destination application data format.

The Response templates are the result of the mapping that has been performed on the source application data format.

The Failure templates are also the result of the mapping but, instead of actual mapped data, they contain error codes and specified error messages because of errors caused by missing data or unexpected server events that might have occurred during application runtime.

For greater detail refer to the USM Implementation Guide for the template content and use of the templates.

Service Definition Files

The service definition JSON files store the data required for the communication between the participating applications. They contain the host URLs of the source and destination applications along with usernames and passwords, if any, for such applications.

These are of the format JSON, meaning the data is stored in a key-value fashion. The USM application uses the RIB-LGF and LogFire URL set here to communicate with the respective applications.

The USM Implementation will give a greater insight about the fields that can be configured and the usage of the file.

Orchestration Files

These files which contain the actual mapping logic. These are in smo format. These files contain scripts that map data coming from a source application to a data format the destination application can work with. The mapping happens with all the fields mapped using a one-to-one mapping. Fields not required, if any, by any of the applications are simply dropped, and non-present fields present in any of the applications is mapped with a predetermined default value.

Note: These scripts are strictly read-only and should not be modified.

Domain Value Maps

A Domain Value Map (DVM) is a table containing mappings between related information in participating applications. They enable you to equate lookup codes and other static values across applications. These DVM tables are used in transforming the messages from one system into the expected format of the other system.

Administrators can extend the list of mapped values by adding more maps. The DVM data should be synchronized with what the participating applications use. This synchronization should occur before any initial loads are run or any incremental transactional flows are initiated.

Data that needs to be stored as foundation/seed data and data that does not have many/any modifications, is stored in Static DVMs. These DVMs are created beforehand. Data can be added or removed at any time but, the data is mostly unchanging data.

Data that is to be stored during runtime of the application is stored in Dynamic DVMs. The data is stored and fetched in these DVMs as per request and the data present here can change, as per request, anytime during the runtime of the application.