Oracle ERP Cloud integration patterns 101: How to use a decision matrix to design integration patterns

This article is part one of the Oracle Enterprise Resource Planning (ERP) Cloud integration patterns three-part series focusing on Oracle ERP Cloud integration fundamentals. In this article, I’ll cover different integration patterns, review how to decide a pattern based on a use case using a decision matrix, and share approaches to use when integrating with Oracle ERP Cloud using MuleSoft.  

The Oracle ERP Cloud is a complete, modern cloud ERP suite with advanced capabilities including analytics to react to market shifts in real-time and automatic updates to stay up-to-date in real-time. It has the following applications to solve specific ERP needs within an enterprise: 

1. Oracle Cloud Financials delivers decisive insights into a company’s financial position and profitability with a comprehensive global solution.
2. Oracle Cloud retail solutions provide a complete set of mission-critical capabilities, cloud services, and hardware. 
3. Oracle Enterprise Performance Management (EPM) enables modeling and planning across finance, HR, supply chain, and sales.

How to use a decision matrix to design integration patterns 

Design integration patterns present conceptual, repeatable solutions to common technology problems. The following architecture principles are recommended to build a decision matrix during the architecture design process to support sustainable enterprise data integration architecture.

1. Use industry-standard connectors to avoid custom development wherever possible: Always use MuleSoft out-of-the-box connectors wherever possible and avoid the use of custom code when connecting with various source and target applications. Connectors always shield the business services from the technology & API changes from the third-party product.
2. Event-driven architecture: Event-driven interactions enable asynchronous communication and reduce the polling overhead on source systems when there is a need to broadcast messages to multiple downstream apps. 
3. Follow API-led architecture: API-led connectivity provides an approach for connecting and exposing assets. With this approach, rather than connecting things point-to-point, every asset becomes a managed API.

The below image shows how to find the right design pattern based on your needs. As an example, if you need to outbound data from Cloud Financials and you have a large volume of data with complex dataweave transformations involved, you would choose the BICC pattern as per the matrix below. 

4 integration patterns for different use cases

Now that you are able to find which integration design pattern to use based on the decision matrix above, I will show you how to implement these patterns with MuleSoft API-led architecture.

1. Business events via Oracle Cloud Financials (CFIN) outbound: ERP business events publish data that can be consumed by MuleSoft applications and further processed to downstream applications. You can also enable pub/sub patterns with Anypoint MQ or a similar messaging platform when there are multiple subscribers interested in the same data.
   • Steps: 
     • The event is generated from Oracle CFIN or Oracle Product Data Hub (PDH). Review the list of business events supporting real-time integrations from PDH.
     • MuleSoft receives the event. 
     • Publish the event into any messaging system for interested subscribers to consume and process.

2. File-Based Data Import (FBDI) pattern with staging database via Oracle Cloud Financials (CFIN) inbound:  This pattern recommends storing the data in an intermediate stage before processing it from the staging database to the Oracle ERP Cloud. This allows you to perform any complex transformation and validation rules against the data. Additionally, you can take advantage of throttling the data from the source to the target in a better way due to the staging database. FBDI is one of the ways to integrate with Oracle ERP Cloud. This pattern is mainly used for loading bulk data into Oracle ERP. The file-based data import process involves generating a FBDI file, uploading the file to ERP, and then receiving a callback from the ERP service. This pattern can be used in any Oracle ERP Cloud app, not just Oracle Finance Cloud. 
   • Steps:
     • Process the input data/message based on the order they come in.
     • Each message will be parked in the storage for a few minutes (parking time) so the system has a chance to throttle the number of messages processed concurrently.
     • A maximal number of the parallel processes can be configured to throttle the outgoing calls.
     • Generate the file in FBDI format based on data received from the source application. It gets triggered through detection of the trigger file or according to the integration schedule. 
       1. Reading source file (based on trigger file name or integration schedule).
       2. Transforming the source file to FBDI.
       3. Staging FBDI file (optional).
     • Load the file generated from above to Oracle ERP Cloud.
     • Once the data is loaded, the Oracle ERP Cloud asynchronously calls back the MuleSoft API with the results of the load & Import processes.

3. Oracle ERP Cloud web services: This pattern recommends SOAP / RESTful Oracle Cloud services by leveraging Oracle standard web services available for the CRUD (Create/ Read/ Update/ Delete) operations. This pattern is applicable for both inbound and outbound.
   • Steps:
     • Source application sends data to the MuleSoft Experience API endpoint.
     • Oracle ERP Cloud exposes web services to publish data and these are available as business objects. The payload received from the source is mapped to the format expected by the Oracle business services.
     • Optional step: The data can be logged into the parking lot DB to maintain traceability and transaction history.
     • MuleSoft makes calls to underlying web services to publish data into Oracle ERP Cloud.
     • The request is processed by Oracle ERP Cloud and the response is sent back.
     • The response is returned to the source system.
     • Optional step: As part of the post-processing, the transaction log is updated in the parking lot database and the user is notified about the completion of the request with status.

4. SQL Reports: This pattern recommends using external report web services from Oracle ERP Cloud, to run a select SQL query against ERP tables. Do not use this pattern when there is a large volume of data because this is best suited for retrieving small data sets like company codes, memo codes, terms and conditions, etc.  

• Steps: 
  • Source application sends a get request to MuleSoft API end-point.
  • Prepare the SOAP payload required for ExternalReportWSSService provided by Oracle ERP Cloud.
  • Use MuleSoft HTTP Request connector to pass this payload to Oracle. 
  • The request is processed by ERP Cloud and a response is sent back.
  • The response is returned to the source system

Summary

It is always recommended to use the right integration pattern when designing your API. In this article, we have reviewed the decision matrix tool which helped us identify the right pattern when connecting to Oracle ERP Cloud for a given set of requirements. 

Using API-led integration patterns with the Oracle ERP Cloud provides a flexible way to orchestrate information with standard API’s and reusable assets as well as quickly and easily deliver information seamlessly across multiple applications in your enterprise.  

To learn more about API-led connectivity, register for MuleSoft Transform to discover the future of connected experiences, connect with experts, and expand your network.