Aleidoc Error Handling

(1)

Complete Guide to Learn ALE Error

Handling Through Workflow and

Implementation

Applies to:

ECC 6.0.

Summary

Through this document the reader will be able to get a detailed idea about the working of the Workflow whenever an error occurred in the ALE Idoc. The idoc at the receiving system will be validated and correspondingly a workflow will be triggered whenever there is an error occurred in the idoc. Authors: Abhijit Daptary, Sunil Ojha and Siddharth Samal

Company: Capgemini Consulting India Pvt. Ltd. Created on: 03 January 2008

Author Bio

Abhijit Daptary is presently working in Capgemini Consulting India Pvt. Ltd as a Consultant. He has experiences in ABAP, Workflow and XI. He has worked in different fields of and has handled various scenarios on Workflow and XI.

Sunil Ojha is a XI certified workflow consultant. His current engagement is with Capgemini Consulting India Pvt. Ltd.

Siddharth Samal presently working in Capgemini Consulting India Pvt. Ltd as a Consultant. He has experiences in ABAP/Workflow.

(2)

ALE Configuration

This section describes the configuration specific to ALE processing.

There are five places in the message transmission process where something can go wrong in the transmission of a message with ALE:

1. Reading the outbound partner profile. 2. Sending the IDoc to the receiving system.

3. Reading the inbound partner profile. This may be a configuration problem or an invalid received IDoc (syntax error or invalid control information)

4. Calling the application function.

5. Posting the record to the receiving database. This is generally a logical error, involving a problem with configuration or with a process problem (such as a customer on credit hold). The first four possible errors are technical errors, involving the distribution of the IDoc without regard to its business contents. An error in posting the IDoc is a logical or functional error, involving a problem with the contents of the IDoc itself, rather than its transfer. We will normally send technical and functional error notifications to different people in an organization.

We can configure Workflow error handling in each of these five error situations. This table lists the areas of Workflow configuration for each possible error situation:

Error situation Workflow configuration needed to handle the error

Reading the outbound partner profile

Maintain the IDoc Administrator on the sending system Sending the IDoc to the

receiving system

Define a Receiver of Notifications in the outbound partner profile

Reading the inbound partner profile

Maintain the IDoc Administrator on the receiving system Calling the application

function

Define a Receiver of Notifications in the inbound partner profile

Posting the document to the database

Configure processing of the corresponding Workflow task

In each case, we can define one or more possible agents to execute the corresponding error-handling task. We can use any of the organizational objects to do this. That is, we can assign all of the members of an organizational unit, a position, or a job to the task, or we can assign a single user or person.

The next sections describe these configurations in detail.

• Idoc Administrator

(4)

Idoc Administrator Transaction: OYEA

Men Path: SALE Æ Error Handling Æ IDoc Administration

The IDoc administrator, called the EDI Administrator in earlier versions, is the agent responsible for handling IDoc errors when no partner profile is available. We can set a single organizational unit, position, job, user, or person as the IDoc administrator. On the outbound system, this error generally indicates a misconfigured system, where a required partner profile is missing. On the inbound system, this error probably indicates that the system received an unexpected message type, or a message from an unknown partner.

(5)

The following table describes each of the error-related fields on this screen:

Field Description

Recipient type The type of organizational object used to identify the possible agents. This can be an organizational unit, a job, a position, a person, or a user.

Identification The organizational object (job, position, etc.) whose members we want to notify of an error.

Max number of syntax errors The maximum number of IDoc syntax error status records to write to the IDoc.

Suppress warnings for status processing

If we select this checkbox, the system will not trigger error handling for errors involving the IDoc’s status records.

Note: You must maintain the IDoc administrator on each system involved in IDoc transfer. You cannot use CTS to transport the settings.

Receiver of Notifications

A Receiver of Notifications is responsible for handling errors in using a partner profile. In this case, the partner profile exists, and the system can read it properly, but there is a problem in sending the IDoc (outbound) or passing it to the application (inbound).

There are four places to define a receiver of notifications:

The partner profile overview screen

Individual partner profile entries for Message Control

Individual partner profile entries for Outbound Parameters

Individual partner profile entries for Inbound Parameters

If an appropriate partner profile exists for the message, but it does not have an entry for the message type in question, then the system will notify the receiver of notifications listed on the overview screen. If the

individual message type entry does exist, then the system will notify the receiver of notifications configured for that message type.

(6)

To designate a receiver of notifications, use the partner profile maintenance transaction WE20, on the Post

processing: permitted agent tab.

The following table describes each of the error-related fields on this screen:

Field Description

Typ The type of organizational object used to identify the

possible agents. This can be an organizational unit, a job, a position, a person, or a user.

Lang. The language to use for the message sent to the receiver.

ID The organizational object (job, position, etc.) whose

members we want to notify of an error.

The screens for the individual message types (Message Control and In/Outbound Parameters) have the same fields.

(7)

Application Processing Errors

There are two ways of processing an inbound idoc and corresponding two ways of error handling for the inbound idoc.

¾ Error handling through the creation of work item

¾ Error handling through the triggering of event attached to the Process code

Error Handling Through the Creation of Work Item

Firstly, describing an error in processing an inbound IDoc results in the creation of a work item. The task used will generally be a foreground input method of a particular IDoc object. That is, each IDoc type defined on the system has a corresponding IDoc business object. There are methods defined for these objects to handle inbound processing of the corresponding IDocs.

Here is an example, using Material Master records:

This is an SAP-supplied Workflow task, called “MATMAS input error”. It uses the business object IDOCMATMAS and its method INPUTFOREGROUND.

To configure the error processing for this error, we must activate the event linkage for the triggering event and designate the possible agents for the Workflow task. The possible agents can be organizational units, positions, jobs, users, or persons.

• Locating the Error Handling task • Activating the Linkages

(8)

Locating the Error Handling Task Transaction: PFTC_DIS

Menu Path: Tools Æ Business Workflow Æ Development Æ Definition Tools Æ Tasks/Task Groups Æ Change

First, you must locate the SAP-supplied task for handling errors in the IDoc type in which you are interested. 1. Execute transaction PFTC_DIS.

2. Enter “Standard Task” under Task type. This indicates a standard single-step task (as opposed to a multi-step workflow).

3. Put the cursor in the Task field and use the drop-down (or press F4) to activate the search. Type the first few letters of the name of the task and press Enter. Most task names begin with the message type they handle. For example, the material master task is "MATMAS input error".

4. Alternatively, you can click on Structure search to bring up the Application Hierarchy. Find the desired task in the hierarchy. Application error handling tasks are generally in the corresponding hierarchy section, while ALE-specific tasks (e.g. Fetch messages) are in the ALE section. For example, you will find the MATMAS error-handling task under Logistics – General Æ Logistics Basic Data Æ Material

Master Æ Standard task Æ MATMAS input error. Double click on the task you want to copy it to the task

maintenance screen.

(9)

Activating the Event Linkage

To activate the event linkage click on Triggering events, then click on the activation button to the left of the event. This button will be green if the event is active, gray if not.

Assigning the Possible Agents

1. To assign possible agents, follow menu path Additional data Æ Agent assignment Æ Maintain.

2. If the words “General task” appears next to the task name, turn off the general task attribute. To do this, click on Attributes, change the properties to General forwarding not allowed, and save. (General

forwarding allowed will also work, but will allow a selected agent to forward the work item to a user not

designated as an agent for the task.) This activates the distribution of the work item according to the possible agents you specify.

3. To assign possible agents to the task, put the cursor on the task name and click on Create (the left-most icon). Select an organizational object, such as a position, job, etc., and specify the specific object to use. 4. Repeat to assign additional possible agents to the task. When done, the screen should look like this:

(10)

Triggering IDOC Error Workflow with Custom Business Object

There are some message types for which there are no Business Objects available, e.g. IDOCDEBMAS for DEBMAS but there is none for BATMAS. To trigger an error workflow following steps need to be done.

• Create a custom Business Object with Super Type IDOCAPPL. • Create a Standard Task; use the above BO in it.

• Bind the task with event (PFTC). • Add the task in Org Plan.

• Create a custom process code using BO in Step1.

Error Handling Through Triggering the Event in Process Code

The error handling will be done through the event triggering and for that an event needs to be created in the BOR object type.

Go to the transaction SWO1. Enter the name in the Object Interface type and click the button CREATE to create the BOR object Type.

Create the Key fields for the BOR object Type.

Click on Key Fields and Click on create button for creating the Key fields.

Click on Events and click on Create button for creating the events. Click on parameters for creating the parameters of the event.

After finally creating the BOR object click on Generate button for generating the BOR and after that change the status of the BOR object to Released.

Create button for creating event or Key fields

Parameters button for setting the parameters of Method or Event

(11)

After complete creation of the BOR object set the status of the BOR object to release.

It is required to have two events corresponding to Start and Stop event. This is because whenever and event is being called it does not start until another event is being called. So, it is necessary to create two events corresponding to start and stop event.

The error handling is being done in the Inbound system. In the Inbound system the idoc is being processed by the Inbound Process code. The process code is being created through the transaction WE42

(12)

Go to the change mode and click the New Entries button for creating new process code.

Button for creating new Process Code

Enter the Process Code Name, description and choose the processing type as Processing by function module. Click on the extension button of Identification.

Extension button for Identification, for the details of the process code

(13)

The details for the of the Process Code after clicking the identification button will be

Enter the function module name, the Object type, the start event and the end event for the error handling. Click the SAVE button for saving the process code. The Start event and the end event will be triggered by the SAP itself.

(14)

Flow of the Process in the Inbound System

When ever the idoc arrives into the Destination system then the standard SAP triggers the Process code attached to the Message type in the partner profile. The partner profile is being maintained in the transaction WE20.

Since, it is and inbound scenario so the message type and the corresponding process code will be maintained for the Inbound Parameters.

(15)

Click on Create Inbound Parameters button for creating new Inbound Message type and the corresponding message type.

Create button for creating the Inbound Parameters

(16)

Enter the process code for the corresponding message type.

Click SAVE button for saving the changes.

Whenever the Idoc arrives into the target system, it checks the partner profile and finds the corresponding process code. The process code is being linked with the function module through which the idoc is required to be processed.

(17)

Diagram Describing the Flow of Process in Inbound System

The event is being triggered by the Standard SAP system.

In this, whenever any error occurred during the processing of the workflow system the event is being triggered and the corresponding workflow attached to the event is being triggered.

Creation of the Workflow and Corresponding Linkage with Event

In order to create a workflow go to the transaction SWDD and click on the create button for creating a new workflow.

(18)

Click on activate, it will ask for the package and an alias name. Enter the alias name and the corresponding package and activate the workflow.

Create button for creating a new workflow

(19)

Since, the workflow is being triggered by the event so it is required to attach the workflow to the event. The event can be attached to the workflow by clicking the Basic Data button.

Basic Data button for attaching the workflow to the triggering event

(20)

On clicking the Basic Data button the following screen will appear. Go to the Start Event tab.

Enter the details of the event with which the workflow should be linked like the category, BOR object type and the event with which that should be linked.

Click on the Binding Button for generating the binding between the event and the workflow.

Binding button for generating the binding between the workflow and event

(21)

Generate the binding and click OK button to save the binding.

(22)

Click on Activate / deactivate button for activating the linkage.

After the successful linkage the following sign will appear on the workflow... Button for activating the linkage with the event and the workflow

(23)

After the successful linkage of the workflow with the event and corresponding configuration of the event at the process code level. It is required for the SAP system to trigger the event at the error condition. In order to trigger the event it is required to set certain parameters for the standard SAP system to trigger the event. The parameters to be set is workflow_result

If the parameter workflow_result is being set to 0 then the standard system will not trigger the workflow otherwise if that parameter workflow_result is set to 9999 then it will stop the processing and trigger the error handling event which in turn trigger the error handling workflow.

Here, the process code function module is setting the parameter workflow_results to 9999, which is actually triggering the event for the error handling.

So, whenever there is an error in the idoc the event will be triggered and the corresponding Idoc will be triggered which will be sending a mail to the respective person.

Workflow results parameter is being set to 9999 resulting in triggering of the error handling event

(24)

Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade.

SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk.

SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.