Showing posts with label ALE / IDOC. Show all posts
Showing posts with label ALE / IDOC. Show all posts

Thursday, November 19, 2009

Triggering workflow event from WE19 (Inbound)

Joyjit Ghosh, Kolkata.

We were trying to test a custom inbound function module where for error it triggers the workflow so that user can be send notification mails with details of the problem.

We were using transaction WE19 to test the FM, for that we had chosen Inbound function module option.

But in SWEL we had found that no event was raised by the FM.

But in our code we had populated workflow variables correctly

Also we had checked the config. and found that this FM is properly configured to raise the event INPUTERROROCCURRED.

After spending few minutes we were able to figure out the problem. We had observed that if we choose Standard Inbound option with ALE Service Check box checked then it triggers the event.

Note: Our custom inbound FM Z_IDOC_INPUT_GOODS_RECEIPT was attached with custom process code ZMIM_POGR.

SWEL:

Then what was the reason for not triggering the workflow? Reason is very simple; workflow is triggered by the ALE layer itself, without ALE layer we cannot trigger the workflow. So if you want to trigger workflow for inbound IDOC from WE19, choose Standard Inbound option with ALE Service Check box checked.



Tuesday, July 28, 2009

ALE Audit

Joyjit Ghosh, Kolkata.

You can configure the receiving system to generate ALE Audit messages for all incoming ALE IDocs for certain message types, and to send these messages to the sending system, where the ALE Audit toolset can use them to maintain a complete audit trail.

To enable ALE Audit:

§ Set up the ALEAUD message type in the Customer Distribution Model and Partner Profiles.

§ Define a filter object in the distribution model to specify the message type that you want to audit.

The data contained within the ALEAUD messages (IDOC type ALEAUD01) provides detailed status information on the IDocs in the receiving system, as well as the links between the IDocs and the resulting SAP application objects on the receiving system.

Audit IDoc Structure

These are the segments in an ALEAUD01 IDoc, with the fields they contain:

§ Segment E1ADHDR

o Message type

§ Segment E1STATE

o Sender’s IDoc number

o Current status

o Message fields

§ Segment E1PRTOB

o Receiver’s IDoc number

o Application object information

Two programs enable cross-system reporting.

§ RBDSTATE. This program is scheduled to run periodically on the destination system. It reports the status of incoming IDocs to the sending system, using the ALEAUD message and ALEAUD01 IDoc. This status information is recorded separately from IDoc status information in the audit logs.

§ RBDAUD01. This program is executed on the sending system. It analyzes the audit log and displays the output as a report.

Program RBDSTATE

Transaction: BDM8

Program: RBDSTATE

Use the program RBDSTATE on the receiving system to send the audit messages to the sending system, using ALE (I.e. asynchronously). You typically run this program as a scheduled batch job. The parameters of RBDSTATE are:

§ The sending system (of the original IDoc)

§ The message type

§ The date range the IDoc’s status was changed. Any IDoc having a status record in this date range will be confirmed.

The audit messages contain:

§ The current status of the inbound IDoc

§ The id of the resulting SAP application object (if the IDoc was
successfully posted)

The system will confirm up to 500 IDocs in one ALEAUD message. If
there are more than 500 IDocs to be audited, then it will create multiple
audit IDocs.

NOTE: The RBDSTATE program looks at IDoc status records to determine which IDocs to audit. If any status record was added to an IDoc during the specified date range, the program will audit the IDoc.

The RBDSTATE program returns the following statuses, from the receiving to the sending system.

Status of IDoc in receiving system

Status reported to sending system via ALEAUD

53 (Application document posted.)

41 (Application document created in receiving system.)

51 (Error: Application document not posted.)

Status 39 (IDoc is in the receiving system.) This status is repeated each time RBDSTATE is run, as long as the IDoc remains in status 51.

68 (Error: No further processing.)

40 (Application document not created in receiving system.)


Program RBDAUD01

Transaction: BDM7

Program: RBDAUD01

Use the program RBDAUD01 on the sending system to look at the ALE Audit IDoc statistics.

§ “IDocs total” is the total number of IDocs audited

§ “Queue Outbound” is the number of IDocs that have not yet been sent to the other system

§ “Queue Inbound” is the number of IDocs that are still being processed by the receiving system

§ ALE Audit records may be selected by message type, date range, etc. You can drill down into the report to see information on daily statistics, detailed information on IDocs, and cross-system links for successfully processed IDocs: