IDoc getting scheduled in stead of processed due to no resources available

[Former Member]

I know this is supposed to go into Basis-forum, but I can't find applicable one. If you can redirect me please do so.

Setup:

-

---

Solution Manager, CUA & ECC6

Issue:

-

---

Sometimes when triggering changes from CUA to an ECC client several IDocs are fired towards that client.

(User Master Record changes, unlocks, role assignments, etc.).

Looking in BD87 I sometimes see that of these IDocs, some are processed directly (transferred to application),

However some of them remain in Status 64 (IDoc ready to be transferred to application).

If I Right-Click -> Process, they are handled perfectly so why did they have to be waiting?

The reason SAP throws for these IDocs is:

Immediate Processing in Job '0000000000005010 '

Message no. EA187

Diagnosis

At the time of IDoc generation, there were no resources for immediate processing and your system is configured so that if this happens, IDoc processing should be started in a job. Therefore, the job '0000000000005010' was started.

Procedure

If the IDoc still has status 64, look for the cause of the error in the log for that job.

Question:

-

---

We have via WE20 profiles set to process all IDocs immediately, then why do some of them still get

scheduled in jobs? (Due to lack of resources for immediate processing?).

Where can I check these 'resources' ?

Edited by: Mujo on Jan 4, 2012 2:41 PM

[Former Member]

I can't help with the resources however have you scheduled a job to pick up the failed USERCLONE idocs & reprocess? That is the standard solution to this problem (when lots of idocs are fired into a single system).

[Former Member]

Hey Alex,

Yes, I have been looking into both available worker processes all seem fine. Also I've been checking to pick up

those IDocs that are in wait-status to be picked up by a (to be) scheduled job.

However a few questions:

- is it common that CUA changes fire multiple IDocs? (in my case 3, only for something trivial as removing 1 composite role

on a CUA-child system with 1 end user

- what I don't really understand yet is if this is fired in batches of (in this case) only 3 IDocs, how come the first is processed and

the other 2 are not? What is blocking that? Is 1 worker process used for processing each IDoc or 1 worker process for all 3 IDocs? To jump into your comment of "when a lot of IDocs are fired", as said: they're only 3.

- can it be that the 'program" that processes the 1st IDoc change to the user master record is then 'occupying' the change mode and that therefore the other 2 are not able to being processed or can it be that the changes just come too fast after one another?

- I would think that when CUA is installed and RFCs and IDoc types are correctly configured this resource problem

should not act up with standard SAP ECC6 settings, for firing something trivial/simple as a composite role change

- last question: if I should schedule a job to pick up the IDocs that are in waiting-to-be-processed status, what is common

interval for this? (every minute? every 5 minutes?) and what's the program to schedule?

EDIT: found at least answer to this question:

RBDAPP01. Processes inbound IDocs (status 64) that have been buffered to support mass

processing. The use of RBDAPP01 in the process flow is described in Chapter 4, "The Inbound EDI

Process." Steps to execute the RBDAPP01 program are listed in Chapter 10, "Testing the EDI

Interface."

Looks strange to me as then the point of CUA making direct changes is somewhat undermined. In this case our CUA is being fed from a Sun IDM system, and the changes on SAP landscape will be 'less near-realtime', if I express that correctly.

Your thoughts are highly appreciated.

Edited by: Mujo on Jan 5, 2012 9:47 AM

Edited by: Mujo on Jan 5, 2012 10:21 AM

[Chrisx]

Mujo,

just wondering if you found out about your resource issue.  I am seeing the same issue in our system.  I understand how to fix the hung up idoc.  I am just wondering if we have a larger problem with resources being "hogged" by another process.

[Bernhard_SAP]

Hello Mujo,

have a look at SAP note 527481, -->solution.

And yes, its normal that always 3 idocs per user and assigned system are created/sent for each user update. (at least in releases lower 710).

Up to that releases there is only the workaround of using zcua_su10 fro reducing the idoc-traffic (note 840154).

b.rgds, Bernhard