Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Best data update approach

Former Member
0 Likes
456

I am currently trying to decide on the best architecture approach for the synchronisation of data between a CRM system and SAP. The CRM system is already built and will be producing files as part of nightly batch containing updates that are required for synchronisation to SAP. Examples of these updates are:

- New Customers

- Updates to existing customer information (e.g. date of birth)

- Regional Structure Updates

and so on….

We do not have a middleware platform, nor can we process the updates asynchronously throughout the day using messages, so we must use a batch approach where the CRM creates a file containing the changes and then we load and update SAP each night.

My questions is should we get the CRM system to format the changes as IDOCs or just create a custom flat file containing the changes?

- If we use IDOCs I assume I can then reuse standard SAP functionality to make the updates to the SAP DB (and I assume that they would be able to tell the different between a create and an update). However the downside is that will be extra complexity in creating correctly formatted IDOC in the CRM system. A follow on question would be - Am I correct in assuming that a single IDOC can contain updates for many different records (e.g. in the case of the batch to update customer information would I need an IDOC for each update or just 1 mega IDOC?

- If we use a flat file format then we will need to create a custom ABAP program to read in the file and call the appreciate methods to either locate and update records or create new ones.

Any guidance would be good, particularly on the relative advantages of using IDOCs over flat files for this type of batch processing.

I am currently trying to decide on the best architecture approach for the synchronisation of data between a CRM system and SAP. The CRM system is already built and will be producing files as part of nightly batch containing updates that are required for synchronisation to SAP. Examples of these updates are:

- New Customers

- Updates to existing customer information (e.g. date of birth)

- Regional Structure Updates

and so on….

We do not have a middleware platform, nor can we process the updates asynchronously throughout the day using messages, so we must use a batch approach where the CRM creates a file containing the changes and then we load and update SAP each night.

My questions is should we get the CRM system to format the changes as IDOCs or just create a custom flat file containing the changes?

- If we use IDOCs I assume I can then reuse standard SAP functionality to make the updates to the SAP DB (and I assume that they would be able to tell the different between a create and an update). However the downside is that will be extra complexity in creating correctly formatted IDOC in the CRM system. A follow on question would be - Am I correct in assuming that a single IDOC can contain updates for many different records (e.g. in the case of the batch to update customer information would I need an IDOC for each update or just 1 mega IDOC?

- If we use a flat file format then we will need to create a custom ABAP program to read in the file and call the appreciate methods to either locate and update records or create new ones.

Any guidance would be good, particularly on the relative advantages of using IDOCs over flat files for this type of batch processing.

2 REPLIES 2
Read only

Former Member
0 Likes
427

Hi Richard,

Welcome to SDN.

I would suggest to use IDoc for interface between SAP and CRM (vice versa).

IDoc technology has excellent error handling and capability to reprocess the error case by case.

It has also good error analysis and testing tool.

Regards,

Ferry Lianto

Read only

Former Member
0 Likes
427

Thanks for that I think I will stick with IDOCs