Get the total number of IDOCs created by a program.

[Former Member]

Experts,

I have a program which creates inbound IDOCs and is run as a batch job. I have a requirement to figure out how many IDOCs were created after each run. The scenario is that I cannot make any changes into the existing batch job to count the number of IDOCs being created. I have to write an additional program which I can run back to back with my IDOC generating program as a batch job and get the number of IDOCs generated by the previous job.

One way I proposed is to read the spool and calculate the number of IDOCs which were pushed in the spool. But this wasn't accepted the other I proposed is to read the time stamp from EDIDC and EDIDS tables before the batch job is run and again read the time stamp after the job is completed and fetch the number of IDOCs generated during this time. The only glitch with this scenario is that there might be other batch jobs which may be using the same Message type and if run during the same time period, may not give me the accurate result.

Can somebody hint me some other better approach ?

Thanks,

Kewal.

[Former Member]

Hi kewal shah

tell me....

you batch job is running with same user id ..?

if not then you can use EDIDS Table to get total number records for each batch run...using user id of batch run...

Thanks

RAMEHS

[Former Member]

Hello Ramesh,

Thank you for responding to my question, appreciate your time.

I thought about this option but its not going to help me because all our batch jobs are run under the same ID.

Thanks,

Kewal.l

[Former Member]

My Issue is still open, Can any expert help me out with this situation -

I want to find out how many Idocs were created after the interface program run (RBDAPP01) was completed. Since I am scheduling this standard program in a batch job, I want to know if I can create a separate program which would fetch me the list of IDOCs created by the previous run of RBDAPP01.

Just for your information: Reading the spool created by the batch job is already thought about and is kept as the last resort. I am looking for some more programmatic way may be some function module or something.

Your Inputs are greatly appreciated.

Thanks,

Kewal.

[Former Member]

Hi Kewal..

got it...

what is the idoc type .. message type ...partner ... partner type you are using ... for two batch programs...??

Thanks

Ramesh

[Former Member]

Hi Kewal,

I doubt that there's a simple way for what you're trying to achieve, though it's a bit unclear what you want:

I want to know if I can create a separate program which would fetch me the list of IDOCs created by the previous run of RBDAPP01.

RBDAPP01 is used for processing existing inbound IDocs and doesn't generate any IDocs unless this is implicitly triggered by processing one of the inbound IDocs (e.g. you could process for example and order change message, which could trigger an order confirmation IDoc). The output list of RBDAPP01 (if requested) would contain only the existing IDoc numbers that have been processed, not any IDocs that were implicitly created.

So let's assume for now that you actually want to access the list of IDocs processed by an RBDAPP01 run. With almost 100% there's no data in the IDoc or the processed application object that links it back to the processing of a specific RBDAPP01 job (unless you have a custom application that would write for example such information into the IDoc status record or some similar area).

Now in theory though you could possibly derive the processed IDocs by comparing the period the previous RBDAPP01 job ran to the IDoc status timestamp of the first status record after the 64 status (including possibly a comparison of user ID to ensure not to pick up any IDocs that were processed by a user manually starting RBDAPP01). This is rather awkward, but should give you the correct results, because one should not run two instances of RBDAPP01 in parallel processing the same IDocs.

If you're at least on ECC 6.0 you could also create an implicit enhancement point for function module IDOC_OUTPUT_LIST evaluating call stack (to ensure it's called from RBDAPP01) and then somehow write a link from the job to the processed IDocs (e.g. in theory you could for example update the IDoc and abuse some field or status record to store the job ID or some other solution).

All of this is rather awkward. Reading the spool also seems questionable to some degree, because you'd have to know for sure that the spool hasn't been deleted (might be irrelevant if your job runs often enough).

In the end you might get some better answers if you describe what you're actually trying to achieve. I.e. why do you need to know which IDocs were processed by a previous RBDAPP01 job? As pointed out also by Ramesh, further details wouldn't hurt....

Cheers, harald

[Former Member]

Thank you Herald & Ramesh !

I am sorry if I am not clear in providing my requirements. To put it in simple terms, I have a batch job which basically runs standard program RBDAPP01 to post (and NOT create) the idocs having status 64 of a certain message type. This job is run frequently (may be twice or thrice a day) and to measure the load processed during each run I need to know how many IDOCs were actually processed and out of which how many were successfully posted during each run.

Per Herald, reading spool may not be a good idea and even we have ruled out the possibility for the same reason.

Another way I thought about is reading the IDOCs based on the date & time stamp using the join of EDIDC and EDIDS and passing the parameters like Message type, status, creation Date and time. Now all our batch jobs are run by the same user but based on the feedback by Herald I agree that it is good to use user name too. The reason I am holding back on using this technique is that I recently came to know that there may be other batch jobs running in parallel which would be posting IDOCS using program RBDAPP01 (not a good practice I know) and it may be possible that they use the same message type too. So there is a chance that I may get inaccurate results occasionally when I use this approach because then, it will be all a matter of timing then.

Ramesh - for your information I am using WYMBXY Message type , Partner type is LS and I have the partner number "HRPCLNT200" as well.

What I am looking for is may be a separate program which I can create and run it as a batch job after the job run of RBDAPP01 is complete and that would give me the number of IDOCS which have been processed in the previous job run. Alternatively, I am also exploring the possibility of any user exit which can give me the count of number of IDOCS which the RBDAPP01 program used for processing and posting.

Just for the kicks, let me throw out another option which crossed my mind last night - Is there any way to link the batch job name with the IDOC number ? May sound stupid but nothing wrong in sharing with you folks.

Thanks,

Kewal.

[Former Member]

I'm still lost why one would need to know the number of IDocs processed via one RBDAPP01 job and somehow seem to fail to understand this based on your responses (my bad). If the idea is to gather some statistics, I'd expect that other metrics are interesting like number of IDocs per day with percentage of of failed IDocs with grouping by error categories, distribution of IDocs over the day (i.e. when are they sent), processing time per IDoc and possibly other system resource related metrics, etc. For such statistics one wouldn't need to link it back to an RBDAPP01 job....

As far as multiple RBDAPP01 jobs are concerned, I think the simple answer is not to do it. I'm not sure what happens with your WYMBXY messages, but I've seen for example cases where multiple orders where posted from a single IDoc due to parallel running RBDAPP01 jobs. So unless somebody tested that you don't end up with duplicate documents or other problems I'd refrain from the questionable practice of running parallel RBDAPP01 jobs.

Anyhow I mentioned before, I don't think there's any link between the IDoc and the job which processed it apart from looking at timings. I don't have any other ideas apart from what has been said, but I'd personally question the need to implement such requirement... (though it might be valid when one understands the full background)

[Former Member]

Ok,

So my requirement is now complete. I could not really find any user exits in RBDAPP01 (which posts the IDOCs) into SAP. However, I found a user exit in the process code of Message Type I am dealing with. So I put my custom code in there to figure out how many IDOCs are being processed by this particular job run. For now, business have agreed to this solution as they are currently monitoring the load on the processing of only one message type. May need to figure out some generic solution later on if the requirement to monitor the additional message types comes up.

Had it been ECC 6.0, life would have been a hell lot easier.

Thank you all for jumping in with your suggestions. Really appreciate that.

Thanks,

Kewal.