performance & IDocs

[Former Member]

Hi,

I have a design question regarding IDocs. I have an interface in which I have to transfer data from SAP system to a legacy system. I want to develop a new IDoc for that interface. The main entity in that interface is an employee.

I have to decide how to design that IDoc. I was thinking about two ways:

1. Create an IDoc that will represent ONE employee (the IDoc will contain 5 segements)

2. Create an IDoc that will represent all the employees that should be transferred (there will be a root segment with 5 child segments, the root segment may appear up to 30000 times)

• In the first way, each time that the interface will run, 30000 IDocs will be created (one for each employee). In the second way, only one IDoc will be created with 6*30000 segments.

Can anyone help ?

Thanks, Nir.

Message was edited by: Nir Marcu

[Former Member]

Dear Nir

If no standard is available, go for proxy.Because

with 1) will have better monitoring of data for each emp, same can be done with proxy also.

2) Message size might become huge, mapping times would be higher, timeouts may occur, finding record of one emp from 30000 would be nearly impossible.

Regards

Monika

[rajasekhar_reddy14]

Hi Nir,

As per my experience i would prefer if there is no standard IDoc then better to go for ABAP proxy/Custom IDoc, only  you have to follow good programming standard while writing code for ABAP Proxy/Custome IDoc.

Insted of going for one IDoc for one employeee not a right approach sometimes definetly you will experice perfromance issuess, so your IDoc/ABAP proxy should handle multiple employee records in one call.

I worked on this kind of scenarions and written abap proxy to support multiple records in one call,never experienced any problems.

Regards,

Raj

[Shabarish_Nair]

stick to standard. if you already have a IDoc from SAP you can handle the requirement with, then use that.

Now coming to all employees in one IDoc or multiple IDocs for each employee, i prefer a single idoc per employee due to the traceability. From a performance point of view, i dont think it should have any major impact as employee data is not a very high frequent data transmission scenario.

[former_member189779]

Hi,

I would prefer option 1 generating IDOC per employee.

Creating one IDOC with 30000 segments, not sure what will be the size of PI message?

Try doing this activity over the weekend.

We have processed 25000 IDOCS on weekend with no problem during go live.

Using proxy, you might need to be sure of error handling mechnisam if something fails.

[MichalKrawczyk]

Hi,

think about matmas, debmas, cremas...

and stay with the standard

Regards,

michal

[Former Member]

Hi Michal,

As I understand, all the IDocs that you've mentioned work like the first way that I described (one IDoc per application document = 30000 IDocs).

Have you worked with IDocs with large volumes ?

Do you think that this is the best way of doing that ?

Nir.

Message was edited by: Nir Marcu

[Former Member]

Just curious... if you have to develope the IDOC and are not using standard ones, then why are you not thinking of ABAP proxies?

Cheers

Manish

[xinjiang_li]

I would prefer the second option. Fewer idocs and resources occupied.

Standard MATMS,CREMAS has more segments to be generated, so one idoc is related to one master data (better status monitoring capability), and also filter can be used in distribution model.

So if we don't have too much fields or segments, then we can consider choosing the second option.

[Former Member]

try to send multiple IDocs with multiple emplyees in each IDoc (say 300 per IDoc)