Data integration scenarios
This unit describes data integration scenarios and patterns that use OData, custom service integrations, and batch data integrations.
OData integration scenario
A retailer uses finance and operations apps for various functions but uses a third-party application to create and maintain their product catalog that is hosted on-premises. The retailer wants to move their product catalog information from the on-premises application to finance and operations. The requirement is that when a product is created or modified in the third-party application, the user will see the same changes in finance and operations apps in real time. OData service endpoints should be used for this integration scenario because real-time data is required. For an integration like this, you should consider doing the following:
- Determine which entities are required for the integration.
- Ensure that the OData service endpoints are available for the same set of entities that were identified as required for the integration.
- In the third-party application, ensure that when the data is created or modified, an OData call is made to finance and operations apps to make the same change.
Custom service integration scenario
A packaging company has a team of customer service representatives that take orders from customers. The company uses finance and operations apps for its warehouses and inventory management. The company also has a third-party SaaS system that it uses for the call center and ordering processes. When a customer service representative puts in an order, the third-party system needs information from finance and operations apps to let the representative know if the item is in stock in real time. This scenario can be implemented by using a custom service. The recommended solution is as follows:
- A custom call is created in finance and operations apps to calculate the physical on-hand inventory for a given item.
- In the third-party application, a real-time call is made to a custom service endpoint through either SOAP or REST to retrieve inventory information for an item.
OData can be used to implement this requirement as well. The prerequisite for using OData is to have a data entity that can be used to either return the requested data or to allow for adding OData actions that would run specific business logic to get the required data. If a data entity is not already available, and its development is not desired for various reasons, then using custom services will be the next choice.
Batch data integration scenario
A retailer uses finance and operations apps for their financials and statement posting. Their point of sale system is a third-party system that runs on-premises. This retailer has several stores that process hundreds of transactions in a day. All the data needs to be imported back into finance and operations apps for their financials at the end of each business day. In this scenario, real-time data is not required because the data needs to be transmitted at the end of the day. This is a high-volume OData that is being processed, and the frequency is just once daily. Therefore, the best solution for this scenario is using batch data APIs. For this solution, the following considerations should be kept in mind:
- In finance and operations apps, it is important to understand all the entities that are required for this integration, and data management needs to be enabled.
- For the on-premises third-party system, REST batch data API should be used to import files into finance and operations apps.