Customizing the Interface for New or Extended IDocs

Overview
  After you extend or develop an IDoc type and the necessary programs, you must configure the system to make these components known to the ALE/EDI interface layer. This chapter shows you how to configure
the system to recognize new components created for the outbound and inbound processes. These settings can be made in the IMG. Some of the settings are also available from the Area menu of EDI(WEDI). These settings are not required if you are using standard SAP processes and have not made any changes to IDocs or programs.

This chapter contains two major sections: configuring the system for new IDocs and configuring the system for extended IDocs. In each section you will learn about configuring the outbound and inbound processes. You should read this chapter as a reference. First, you should identify the section that describes your scenario, and then you should branch directly to the steps that pertain to the scenario you are trying to configure.

Configuring the System for New IDocs

This section explains how to make a custom basic IDoc type and its programs known to the ALE/EDI interface layer. 

Configuring an Outbound Process for New IDocs

The steps for configuring an outbound process depend on the type of program you have developed for the outbound IDoc. Three types of outbound programs were discussed in the preceding chapter: IDocs via Message control, IDocs from stand-alone programs, and IDocs from change pointers. Each requires a slightly different setup. To describe the procedure, the monthly report IDoc and its programs are used as an example. Configuring an Outbound Process That Uses Message Control You carry out the steps listed here if your outbound process uses Message control and you have replaced a standard SAP-provided function module with your custom function module to generate custom IDocs. The following steps describe how you configure the system so that Message control invokes your custom programs and generates custom IDocs.
1. Create a new message type.
2. Link the IDoc type to the message type.
3. Create a new process code.
4. Create or change a partner profile to add a Message control record and an outbound record.

Create a New Message Type

Transaction: WE81
Menu Path: From the Area menu of EDI, choose Development, Message Types.
You assign a message type to the data contents transferred in the IDoc and give it a short description. Customer-defined messages begin with Z. This should be the same name used in your IDoc programs. For the monthly report IDoc, message type ZMREPT is chosen. 

Link the IDoc Type to the Message Type
Transaction: WE82
Menu Path: From the Area menu of EDI, choose Development, IDoc Type/Message.
You assign the message type created in the preceding step to the IDoc type.This step not only serves to document which message is based on which IDoc type, but it also checks this link in the process when IDocs are generated.

Create a New Process Code
Transaction: WE41
Menu Path: From the Area menu of EDI, choose Control, Outbound Process Code. This step assigns a process code to the function module created for the outbound process. The process code is an indirect means of identifying the function module.

Create or Change a Partner Profile
Transaction: WE20
Menu Path: From the Area menu of EDI, choose IDoc, Partner Profile.
A partner profile is created for every partner system that sends or receives IDocs. In the partner profile, a Message control record and an outbound record are created for each outbound message that operates
under Message control. Create a partner profile if it does not exist.. Add the outbound record and the Message control recor for your message. This step assumes that Message control components such as the Application and Output type have already been configured.

Configuring an Outbound Process for Stand-Alone Programs
You carry out the steps listed here if your outbound program is developed as a stand-alone program to generate IDocs. These programs are mainly designed for master data distribution in ALE and interfaces
with legacy systems. Here are the configuration steps.
1. Create a new message type. 
2. Link the IDoc type to the message type.
3. Add the message to the ALE distribution model (optional).
4. Create or change the partner profile.
Steps 1 and 2 are the same as described earlier in the "Configuring an Outbound Process That Uses Message Control" section. Step 3 is new, and Step 4 is slightly different.

Add the Message to the Customer Distribution Model
Transaction: BD64
Menu Path: From the ALE configuration in the IMG, choose Modeling and  Implementing Business Processes, Maintain Distribution Model and Distribute Views. Here you add your message to the distribution model. This step is necessary only if you have not specified the receiving partner in the control record within your program 

Create or Change the Partner Profile
Transaction: WE20
Menu Path: From the Area menu of EDI, choose IDoc, Partner Profile.
In the partner profile, an outbound record is created for each outbound message generated from stand-alone programs. Note that the Message control record is not created in this case because stand-alone programs do not use the Message control component. specified in the outbound record of a partner profile. Configuring the Change Pointers for an Outbound Process The following steps describe how you configure the system so that RBDMIDOC calls your custom program. You carry out these steps if you have developed an IDoc generation program using change pointers. These programs are designed to generate IDocs based on changes to a document or master data. The RBDMIDOC program reads configuration tables to determine the appropriate IDoc generation program for a particular message type. The settings for those configuration tables are as follows.
1. Create a new message type.
2. Link the IDoc type to the message type.
3. Make sure that the change pointers are globally activated.
4. Activate the change pointers for your message type.
5. Link the message type to the function module.
6. Add the message to the ALE distribution model (optional).
7. Create the partner profile. Steps 1 and 2 are the same as those described in the "Configuring an Outbound Process That Uses Message Control" section earlier in the chapter. Steps 3, 4, and 5 regarding change pointers are new. Steps 6 and 7 are the same as steps 3 and 4 of the "Configuring an Outbound Process for Stand-Alone Programs" section earlier in this chapter. 

Verify Global Activation of the Change Pointers
Transaction: BD61
Menu Path: From the ALE configuration in the IMG (SALE), choose Distribution Scenarios, Master Data Distribution, Activate Change Pointer, Activate Change Pointer (generally).
You must make sure that the change pointer process is active. Execute transaction BD61, and activate the change pointer process if it's not already active.

Activate the Change Pointers for the Custom Message
Transaction: BD50
Menu Path: From the ALE configuration in the IMG, choose Modeling and
Implementing Business Processes, Master Data Distribution, Replication of Modified Data, Activate Change Pointers for Message Types. Also, for each individual message, change pointers have to be activated. Execute transaction BD50, and add an entry for your custom message. 

Link the Message Type to the Function Module
Transaction: BD60
The message type also needs to be linked to the function module developed for analyzing the change pointers. Execute transaction BD60, and add an entry for your custom message.

Configuring an Inbound Process for New IDocs
As mentioned in the preceding chapter, the inbound IDoc process is the same no matter which outbound process is used to generate an IDoc. The inbound configuration for a new process can be divided into two parts: process configuration and workflow configuration for exception handling. The steps for process configuration require some of the components defined in the workflow configuration, so it is necessary to maintain the workflow configuration before maintaining the process configuration.

Workflow Configuration
Workflow configuration is necessary for exception handling in the inbound process. The elements used in the exception-handling process can be understood by looking at the process flow. When an application error occurs, an event is raised. This event is called a triggering event, and it is part of the IDoc application object. For standard messages, the triggering event is named INPUTERROROCCURRED. The triggering event is linked to a workflow error task. The task is started, and a work item appears in a user's inbox. The user processes the work item. At the end, the system raises a terminating event to mark the completion of the work item. The terminating event is also part of the IDoc application object. For standard messages, the terminating events are named INPUTFINISHED. From this process, you will see that the system needs to know the IDoc application object, triggering event, terminating event, task, and the linkage between the triggering event and task.
The steps to make these components known to the system are as follows.
1. Create a new IDoc application object in the business object repository with triggering and terminating events.
2. Create a new task based on the application IDoc object.
3. Create the event linkage.
4. Create a new IDoc packet object in the business object repository (optional).
Create a New Application IDoc Object in the Business Object Repository
Your objective is to create an IDoc application object for your message. The best option is to copy an existing IDoc application object and change the necessary settings. Follow these simple steps.
1. Execute transaction SWO1, or use the path from the SAP standard menu, Tools, Business Workflow, Development, Definition Tools, Business Object Builder.
2. Click the Find icon (it looks like a pair of binoculars), and expand the selection options by clicking the All Selections icon. Enter IDOCAPPL in the Supertypes field and click the Execute icon.
3. Click any object, and select Business Objects, Copy from the drop-down menu. The system prompts for information required to copy the object. 

Note  Make sure that the object being copied has the INPUTERROROCCURED and INPUTFINISHED events. You can confirm this by double-clicking the object and then verifying the event list. 
4. Assign a name for the object type and the program. The names must start with a Z. Click the Copy button. When prompted, enter the development class. This step should create an entry in the object list at the bottom.
5. Double-click the newly created entry. Click the Basic Data icon (it looks like a hat). Click the Change icon in the application toolbar, and change the name and description to match your IDoc.

Create a New Task Based on the Application IDoc Object
A workflow task defines the task attributes that have to be carried out when an application error occurs.
You must create a task for your inbound process. A task points to an object method to be executed and to the triggering event that starts the task. The best option is to copy an existing task, such as Orders_error (TS00008046). Follow these simple steps.
1. Execute transaction PFTC_COP or use the SAP standard menu path, Tools, Business Workflow, Development, Definition Tools, Tasks/Task Groups, Copy.
2. Click the Tasks button. Select Standard Task for the task type and enter the task number for Orders_Error (00008046) as the Task. Click the Copy icon.
3. Enter an abbreviation and name for the task. Press Enter. This should copy the task. Note the number.
4. Execute transaction PFTC_CHG, select Standard Task as the task type, enter the task number noted in Step 3 in the Task field, and click the Change icon
5. Replace the object type field with the IDoc application object you created in the "Create a New Application IDoc Object in the Business Object Repository" section.
6. Now you change the triggering event. Click the Triggering Events tab to go to the triggering event screen. Delete the existing event, and then create another event based on your object type. Click
the Insert Event button. Enter your object type and the INPUTERROROCCURRED event.
7. You are ready to define the binding of data between triggering the event and the task. A binding between two elements is basically saying a = b in a programming language. Select the triggering event by clicking the selection button at the left of the line containing your new event. Click the Binding icon. In the Expression column, press F4 and select the default entry (highlighted in green). Perform the same operation for the Exception field. You can also click the Check icon for testing the consistency in binding. Click the Green check mark to go back to the triggering event screen.
8. Now you activate the linkage between your task and triggering event. Click the Event Linkage button. This step activates your linkage.

Note  Step 8 takes care of the third requirement for maintaining workflow configuration for the inbound process for a new IDoc-creating the event linkage. Now that you've established this link between the event and the workflow task, the workflow system uses the link to start the task whenever the event is raised. 
9. You now define the terminating event. Click the Terminating Events tab. Delete the entry that exists from the copy operation. Next, click the Insert Event button and enter the values for Object Type, Event (this should be the terminating event INPUTFINISHED), and Element. For Element, press F4 and select the only entry. See Figure 33.12 for the terminating event defined for the customer task for the monthly report IDoc. Press Enter and click the green arrow icon in the application
toolbar to go back.
10. Make your task a general task so that anyone can execute it. Choose Additional Data, Agent Assignment, Maintain. Click the task to select it, and then click the Properties button. Select the General Task radio button. Press Enter and click the green arrow icon in the
application toolbar to go back.
11. Save your task. Create a New IDoc Packet Object in the Business Object Repository (Optional) This object is used for processes that are capable of processing many IDocs. Follow the steps outlined in
the "Create a New Application IDoc Object in the Business Object Repository" section earlier in the chapter, but this time, use IDOCPACKET instead of IDOCAPPL as the starting point. 

Process Configuration
After you create the necessary workflow configuration, you can carry out the steps for process
configuration.
1. Create a new message type.
2. Link the message type to the IDoc type.
3. Allocate the function module to the logical message type.
4. Define the attributes for the inbound function module.
5. Create a new process code.
6. Assign input methods
7. Create (or change) a partner profile.

Create a New Message Type
Transaction: WE81
Menu Path: From the Area menu of EDI, choose Development, Message Types.
Just like the outbound process, the inbound process requires a message type assigned to the data contents transferred in the IDoc. Customer-defined messages begin with Z. The name of the message type should be the same name used in your IDoc programs. For the monthly report IDoc, message type ZMREPT is chosen. If you have already created this entry in your system for the outbound process, you can ignore this step.

Link the IDoc Type to the Message Type
Transaction: WE82
Menu Path: From the Area menu of EDI, choose Development, IDoc Type/Message.
You assign the new message type to the IDoc type. This step is also similar to the outbound process.

Allocate the Function Module to the Logical Message
Transaction: WE57
Menu Path: From the Area menu of EDI, choose Development, Message/Application Object.
This configuration establishes a link between the function module, message variant (message type, message function, message code), IDoc type, and business object created by the function module. The
Business Object field is optional.

Note   In the case of outbound messages, this link is established in the partner profile. For inbound messages, there is no entry for an IDoc type in the partner profile, so this entry is used to establish a valid IDoc type, message, and business object for a function module. 

Define the Settings for the Inbound Function Module
Transaction: BD51
Menu Path: From the SAP standard menu, choose Tools, ALE, ALE Development, 
IDocs, Inbound Processing, Function Module, Define Attributes.
This configuration step tells the ALE system how your function module has been implemented. The ALE layer uses these settings to invoke the function module with correct parameters. In the Input Type field, the possible values are
ƒ  Mass processing (0). This option is for function modules that use a direct input method to create an application document. The ALE layer can pass multiple IDocs to the function module at the same
time.
ƒ  Individual input (1). This option is for function modules that use the call transaction method to post an application document.
  Individual input with IDoc lock in call transaction (2). This option is for function modules that use ALE-enabled transactions to post an application document.
The Dialog Allowed field indicates whether the IDoc can be posted in a dialog mode after an error. If this option is turned on, the user can watch each screen during input processing. 

Create a New Process Code
Transaction: WE42
Menu Path: From the Area menu of EDI, choose Control, Inbound Process Code.
This step defines a process code that points to the function module developed for the inbound process. Process codes provide an indirect means of determining the process (in this case, the function module).
Using process codes enables you to change the process without ffecting other configurations. The process code must start with a Z. Assign a short description, and then save your entry. The system prompts you with the following message: Please maintain codes added in 'ALE
entry methods.' Accept the message by pressing Enter, and you are taken to a screen that shows the existing links between process codes and function modules. 

Assign Input Methods
Transaction: BD67 or WE42
Menu Path: From the Area menu of EDI, choose Control, Inbound Process Code.
This step creates a link between the process code defined in the preceding step and the function module. Also, this screen contains additional parameters that the workflow component uses for error handling, as well as for advanced workflow programming. You enter the process code, function module, and workflow components developed earlier in the "Workflow Configuration" section.  You can leave the Application Object fields blank for the monthly report scenario. These fields are used to specify the application event that should be raised after the application document has been posted successfully. To take advantage of this field, the inbound function module has to be coded using the advanced workflow programming technique. For details, refer to the ALE programming guide in SAP's online help.

Create or Change the Partner Profile
Transaction: WE20
Menu Path: From the Area menu of EDI, choose IDoc, Partner Profile.
A partner profile is created for every partner system with which you exchange IDocs. In the partner profile, a record is created for every incoming message. Create a partner profile if it does not exist. Add a record for your incoming message.

Configuring the System for Extended IDocs
In this section you will learn how to make IDoc extensions known to the ALE/EDI interface layer. The programs for IDoc extensions are already known to the ALE/EDI interface because these programs are
written in the user exits that are part of the standard SAP programs. Therefore, the only requirement is to make the extended IDoc known to the system.

Configuring an Outbound Process for Extended IDocs
The outbound process requires only two configuration settings: establishing a link between the message type, IDoc type, and IDoc extension, and establishing the outbound parameters for the partner profile. 
Establishing a Link between the Message Type, IDoc Type, and IDoc Extension
Transaction: WE82
Menu Path: From the Area menu of EDI, choose Development, IDoc Type/Message.
This step links the standard SAP message to your new extended IDoc while maintaining the original settings of the SAP basic IDoc type. This arrangement is possible because SAP permits a message type
to be based on different versions of the IDocs.

The Partner Profile: Outbound Parameters
Transaction: WE20
Menu Path: From the Area menu of EDI, choose IDoc, Partner Profile.
Here you specify the message type, basic IDoc type, and extension (if any) you want to use for the outbound process. 

Configuring an Inbound Process for Extended IDocs
The inbound process needs only one configuration setting to make the IDoc extension known to the system, as described in the following sections. Notice that you do not have to make any change to the
inbound record of the partner profile because the inbound view does not have any mention of the IDoc type. 
Establishing a Link between the Message Type, IDoc Type, and IDoc Extension