Workflow for Beginners

1:Find a standard business object - which relates to the desired master data.
Transaction SWLD
Definition Tools àSAP Business WorkflowàDevelopmentàDefinition ToolsàBusiness Object Builder (Transaction Code SW01)
Click on the Business Object Builder. The initial screen appears as follows.
Either search for an object by name in short description. Or use the IMG structure, which is accessed via the Business Object Repository button.
Position mouse cursor in the field Object/interface type and hit F4àIn the pop up window click Information SystemàSearch the business object created earlier or SAP standard business object. àSelect it and click display
Select all object types and the following screen appears. Here the businisess object BUS2054 has been explored, which is under Project Systems.
A business object has following components as shown in the figure:
A screen showing the components of the object is dispalyed as the following figure:
2:Create a business object.
Give the business object name prefixed with Z_.
Enter the following fields with values:
Object type: Z_TESTXX
This is the internal technical key. Page: 1Object type can have maximum 10 characters. This must be unique across all object type. Objects are specific instances of object types at runtime.
Object name: Object_Name_for_XX
The object type is addressed with this name by external applications. This is a descriptive English name and can be up to 32 characters. This also must be unique across all object type.
Name: Object Name: XX
This is a meaningful name of the business object.

Description: Object Description: XX
Page: 1Object description, can be up to 40 characters.

Program: Z_TESTXX
Each object type has an ABAP/4 program in which methods of the object are implemented. This program is generated automatically when you create or revise an object type.

Application: *
Page: 1* indicates cross application.

Should you need to extend the components of an SAP delivered object, you can create a subtype and then “delegate” it back up to its supertype. This means that the supertype transparently acquires the new functionality. If this supertype is referenced by any SAP or custom application, the new functionality is available. Any supertype may have at most one delegation assigned to it. Delegations are client independent. Use the menu path Settings >System-wide to create a delegation.
3: Create an event.

Open the Object type in change mode. When you change your subtype the first step is to create a new event, this is done by selecting the Event node and clicking the create button. Give the event a name and a description. Next set the status of this object type component to implemented.

Event: Z_EVENT_XX
Name: Event name: XX
Description: Event Description: XX
Click on the new event and…
Edit à Change Release Status à Object Type Component à Implemented
(A small box sign vanishes from the right side of the event, indicating that it is implemented)
There can be multiple triggering events for a standard/customer task.

In R/3 4.0 the release strategy for new Object Types and Object Type Components (methods, attributes, events, etc.) was enhanced. Now when an object type and/or components are created, there are different statuses to select, based on its required purpose. The statuses are:
· Modeled - objects cannot be accessed at runtime. This is the status that is automatically set when an object type or component is created. Items with a modeled status cannot be referenced in any type of workflow task.
· Implemented - objects can be used internally in a test environment. They are accessible, but may not be stable (especially if no delegation has been defined).
· Released - objects are ready for production. Note: Local objects cannot be released.
· Obsolete - objects are typically replaced by new functionality or incompatible with previous versions. This status is optional.
4: Create a method.

Next a method must be created without using any function module template. When creating the method ensure that the method call is synchronous - this means that the method doesn't require a terminating event.
A method can be synchronous or asynchronous. Synchronous Method
Method that, for the duration of its execution, assumes the process control and, after its execution, reports to the calling component (work item manager, in this case).
Synchronous methods can return the following data, if defined: Return parameters, one result and Exceptions.

Terminating events can also be defined for a single-step task described with a synchronous method. At runtime, the relevant work item is then terminated either when the synchronous method is successfully executed or when one of the defined terminating events occurs.

Asynchronous Method
Method that, after its execution, does not report directly to the calling component (work item manager, in this case).
Asynchronous object methods do not return results, parameters or exceptions.
At least one terminating event must be defined for a single-step task described with an asynchronous object method.
At runtime, the relevant work item is only terminated if one of the defined terminating events occurs.

Next set the status of this object type component to implemented. The methods are not implemented unless you once open their program. Select the method and open its program. It gives a message “Do you want to generate a template automatically for the missing section”. Click “Yes”. Inside the program insert the code “CALL TRANSACTION ‘FB03’. Display Financial Document.

Method: Z_METHODXX
Name: Method name: XX
Description: Method Description: XX


Edit à Change Release Status à Object Type Component à Implemented

5. Create Key fields.

Create key fields with ABAP dictionary field proposal.
It is the identifying key, via which the system can access a specific object, that is, an instance of the object type. The key fields of an object type are usually also the key fields in the table containing the header data for the object type. Only character-based data types are allowed as key fields. The total length allowed for all key fields is 70 characters. Each key field refers to a field in the ABAP Dictionary.
Enter ‘BKPF’ in table name field and select all the key fields. Press Continue button. Next set the status of these key fields to implemented.

Edit à Change Release Status à Object Type Component à Implemented
6:Implement business object.

The whole business object needs to be implemented so click on the business object title and…
Edit à Change Release Status à Object Type à Implemented

Now you can check the syntax, generate the Business Object and then test it. Execute the custom method you created and give the Company code, Document number and Year.

7:Create workflow task.

Now we need to create a workflow task, this will be triggered by the event and will call the desired method in your business object subtype/Object type.
Tasks to user means generic actions, which are in the responsibility of a person (agent) or group of persons (agents), that, may have to be done in a predefined interval.
Runtime execution of a single step task produces a work item in the selected agents integrated inbox.


Transaction SWLD
Definition Tools à Tasks/Task Group à Create

This task will be of type TS (Standard Task)
Tasks are of two types. Standard and Customer tasks.
Standard tasks (object Type TS) are supplied by SAP and can also be created by the customer, they are client independent.
Customer tasks (object Type TS) are client dependent and created by the customer.
(SAP’s recommendation is that all new tasks should be of type TS) after this is entered click the create icon (Don’t give the Task number, it will be created automatically).

This will bring up the main task window. Under the Basic Data tab enter the Abbreviated Name (this name should be unique for tasks), Name and Work Item Text. Enter your business object subtype/ object type name as the Object Type and enter the Method you created within the subtype / object type. If you tick Background Processing as the execution mode, the work item is executed without need for manual intervention.

Next move to the Triggering Events tab. Insert a new entry in the table here - referencing the business object subtype/ object type and the relevant event.
When this event occurs, the system starts this task. Another event is Terminating Event: When this event occurs, the system terminates the work item for this single-step task.
(If the single-step task has the property Confirm end of processing, the work item is not terminated when the event occurs. The work item must still be set to ‘Done’ by one of its recipients.)
Use:
Single-step tasks that refer to an asynchronous method must have at least one terminating event.
Single-step tasks that refer to a synchronous method can have terminating events.
8: Set up containers.

There are a number of data containers, which are used in this process to transport relevant data between events, tasks and methods, we need to make a few small modifications to these.

Click on the Containers button. Now click the Create button. Create three fields in the container with reference to the database table. For the first field give reference table name as ‘BKPF’ and reference field name as ‘BUKRS’, for the second give reference field ‘BELNR’ and ‘GJAHR’ for the third. Now go back to the Triggering Event tab, highlight the newly created record in the table and click the Binding Definition button.
This shows us how data is transferred from the Event container into the Task container. There should be four records. Now click on the Event Parameter Container button, this shows us what data is present in the event for transfer to the task. If there is matching data in the Event Parameter Container, copy the element name from the screen and insert it in to the associated slot in the binding definition (Enclosed in &'s).

The last step of all is to activate the event linkage, by pressing the small red button to the left-hand side of the event record. When it is activated it becomes green. This creates the link between the event and the task - which will call the method, which in turn calls the required transaction or reports or function module.

9: Assigning agent to a Task.
Determine the possible Agents for executing the single step Task.
An agent is an executor of a work item.
• A work item is the actual runtime representation of a workflow process step (task). Work items appear in users’ integrated inboxes.
• Possible agents are a collection of agents who qualify to execute a work item, and therefore could potentially receive a work item in their integrated inboxes.
• Selected agents are those possible agents (1 or more) who are elected to execute a task at runtime. They actually receive the work item in theirintegrated inboxes.
• The actual agent is the agent among those selected agents who actually processes the work item. When the actual agent processes this work item, it disappears from the integrated inboxes of any other selected agents.
• At runtime, a pool of selected and actual agents can be created for the following types of actual agents:
– The processing agent: The person(s) who actually processes the work item.
– The deadline agent: The person(s) informed when a work item is not processed fully within the specified deadline. This notification is received via a deadline work item in the deadline agent’s integrated inbox.
• The notification agent: The person(s) notified when an activity step is fully processed. This notification is received via notification e-mail in the notification agent’s SAP office e-mail. The notification


agent is informed if a work item or workflow has been processed and the status of the work item is “completed” or “logically deleted”.

Responsibility can be assigned to a single person, to multiple people (a shared task) based on jobs, positions or organizational unit. This flexible assignment provides the greatest stability and maintainability since the tasks do not have to be reassigned every time specific employee changes and the workflow definition do not need to be changed. The possible agents designated at the single-step task level must already have SAP authorization to execute the functionality in the method. If they don’t, when the task becomes a work item at runtime and the user attempts to execute it, they will get a message: - “You are not authorized to execute this transaction”.
Agents are an important part of tasks. Agents (capable executors of the task) must be assigned to the single-step task. (Within the task definition, Additional data®Agent assignment®Maintain.) These are the agents drawn from the organizational plan who are qualified to perform the task.
10: For this demo example, you will trigger the event by writing a custom code.
The starting point of a workflow is the object/event trigger. Without this the possibility of building a workflow is ruled out. The triggering of events is achieved through a number of mechanisms some of them are listed below:

Events can be created in the following ways:
Change document
Status management
Message control
Custom code: The function module SWE_EVENT_CREATE is used to trigger the event. Don’t forget to write a commit work after the function module call.
11. A Single Step Task.
By now you have defined a Business Object with key fields Company code, Accounting document number and Fiscal year. You have created a method and an event for the Business Object. You have also defined the Task for linking the method and event and also defined containers and performed the binding definition. You have also defined the custom code to trigger the event. Now, your objective is to display financial document using CALL TRANSACTION ‘FB03’, when the event is triggered. For this you must put the following piece of code inside the method of the object and generate it.
Check that you have given your username in the agent assignment section of the task. Now when you execute the custom code the event will be triggered, so the key fields will be inside the event container, from there it will pass on to the task containers you have defined. This transfer is controlled by the binding definition you established before activating the task. From the task container the key fields will be available inside the Business Object. Thus they will be assessable inside the Object Method, where you use them to display the financial document.

12. Some Workflow Concepts

What is Workflow: Workflow is a tool to automate business process

Workflow can be single step or multiple steps.
Single step workflows are “Tasks” and multiple step workflows are “Templates”.
Workflow determines which tasks are executed, when, under which conditions and by whom.
Workflow definition is made up of individual steps. When creating a step in a workflow definition, the step type must be specified first. Specify the step type as Activity here.
Activity can be a single step task with basic business functionality
Can be a multi-step task, which reference to a workflow definition
What are the different elements of Workflow:
Tasks: Activity in which an object method is carried out.
Business Objects: Identifiable specific instances of an object type.
Work Item: A work item is an actual representation of a task.
Agent: An agent is an executor of a work item. Types of agents:
Possible agent
Deadline agent
Notification agent
Methods:
Events
Containers:
Containers are used to store field values, multi-line lists of field values, object references and multi-line lists of object references.

All import/export parameters of the workflow tasks/workflow templates are specified as elements of the workflow container.
Containers only contain control information for the workflow system.
Containers do not contain application business data.
Binding:
Binding definition executed at runtime
Used for transferring data from one container to another container
Used for assigning values to container elements
Binding is always performed with reference to the elements of a container.
Data flows between the workflow components as follows:
1) Triggering event is created in application.
2) The workflow receives the application data from the event.
3) The workflow step transfers application data from the workflow to the synchronous customer/standard task.
4) The task transfers application data from the task to the object method parameters.
5) The execution of the object method may change the application data. The object method parameters transfer data to the task.
6) The task transfers application data back to the workflow.
7) The workflow step transfers application data from the workflow to the synchronous customer/standard task.
8) The workflow step transfers application data to the standard role parameters.
9) The task transfers application data from the task to the object method parameters.
10) The execution of the object method may change the application data. The object method parameters transfer data to the task.
11) The task transfers application data back to the workflow.
12) The workflow step transfers application data from the workflow to the asynchronous customer/standard task.
13) The task transfers application data from the task to the object method parameters.
14) The terminating event transfers application data to the task.
15) The task transfers application data back to the workflow.

The dataflow between the application and workflow container elements and between the elements of the workflow container, event containers, task containers, role containers, and method parameter containers is controlled by a set of rules called the binding definition.

Introduction to ALE and IDocs

IDoc Definition and Use

An IDoc stands for ‘intermediate document’; it is a container for exchanging data between R/3, R/2 and non-SAP systems. ALE (Application Link Enabling) uses IDocs to exchange data between logical systems. Non SAP-systems can use IDocs as the standard interface for data transfer.

IDocs are created by messages; a check is made on the message types that the sending and receiving operating systems allow. These are then used to process the IDoc.

An Idoc type specifies the structure of the data. A message type specifies the meaning of the data. An Idoc type must be assigned to a Message type so that the data in the Idoc is processed correctly.

An IDoc contains only character fields. However, the data elements within segments can be of any format as data is moved and automatically converted into a character field (EDID4-SDATA) before being transferred into the IDoc.

SAP has its own standard Idocs with segments containing certain fields. If an Idoc does not contain all of the required fields, it can be extended whereby additional segments are inserted into the Idoc.

Idocs can also be reduced. This is where they are modified to only include the data that is valuable to the receiving system. Note, Idocs can only be reduced for master data. Reduced Idocs cannot be used with Mercator.

If an SAP Idoc does not exist, custom Idocs are created.

IDoc Structure

An IDoc is a configuration of an IDoc type that determines the IDoc structure.
IDocs consist of a Header, several Data Segments and Status Records.
The functions of the individual elements of an IDoc are as follows:

· An Idoc has a control record that stores the characteristics of the Idoc. The contents, sender, receiver and current status of the IDoc are defined in this control record.
Table: EDIDC holds the Control record details.
There is one control record for each IDoc Structure.

· Each Data Segment contains a standard header consisting of a sequential number, a description of the segment type and a 1000 character long string containing the actual data of the segment (field name = sdata).
Each IDoc must have at least one Segment. Secondary Segments are optional.
Table: EDID4 holds the IDoc Data Records.

This table will hold all records to be transferred into the IDoc. The number of records will equal the number of segments.
Note: The complete contents of the 1000 character field ‘sdata’ cannot be viewed unless the ‘List Width’ of the table is changed from 250 to 1023. This is done through transaction code SE11 when the table’s contents are executed.

· Status Records show the history of the processing steps applied to the IDoc.
For example: the client, the time of creation, the user etc.
Table: EDIDS - Status Record (IDoc). - There can be multiple status records for each IDoc.
Table EDIDS does not need to be mentioned in the actual ABAP code.

Consider the set up of the following IDoc structure:

This IDoc structure illustrates: -
· The various hierarchical relationships.
· The number of times a segment can occur (MIN/MAX).
· Whether the segment is Mandatory or Optional.

All of the above needs to be considered when analysing the structure of the IDoc being created.

It can be seen that an Article can have multiple Pricing Conditions, therefore the Article segment will be created as hierarchy level (HL) 02, and the Pricing Conditions as HL 03.

This IDoc will have the following structure in EDID4.
(The SEGNUM is the segment number done in sequence of when written to the IDoc. The PSGNUM is the number of the hierarchically higher segment.)

Error Handling

Error Handling in ALE can be handled using Workflow technology.
When an error occurs in an ALE/EDI interface, it triggers an event, which initiates a task associated with it. This triggering will eventually send an appropriate message to a predefined user inbox.
There are two types of errors – technical errors and functional errors.

Error Handling will be project specific; one way of dealing with errors is illustrated below:
All errors must be handled in a common way – the procedure to be adopted involves a designated user being informed of any / all records that are rejected from the interface (and the corresponding reason for rejection) via the SAP in-box functionality that is accessed via transaction SIN1. Thus, whenever this designated user logs into SAP, a notification message will appear informing of any errors from the previous night’s batch processing.

To ensure that users are informed immediately of any errors that occur and where they have occurred function module ‘MC_SEND_MAIL’ is to be used. This will send to the designated user a mail indicating where in the process the interface failed.

For all interfaces, if there are any serious SQL errors for any select statements within a program which would cause the processing to stop then the function module should be called.

Outbound Interfaces
On a more specific level, it needs to be determined for each system interfacing with SAP:

a) If no data is selected at all from SAP, what notification to be sent out to Mercator and the designated user
b) Which fields must be filled for the receiving system, and if these are not filled, how
to handle these errors and what notification is to be sent to the designated user.


Key Terms

IDoc Type
The IDoc type describes the technical structure of a message. It defines which segments will be used and what is the hierarchical structure of the segments. For each segment it also specifies whether it is mandatory or optional and how many times the segment may appear in the IDOC.

MESSAGE Type
The Message Type describes the contents of the ‘sdata’ field in the data structure that is passed to the function module ‘Master Idoc Distribute’. It passes the information to the FM on how to populate data into the segments of the Idoc.

SECTION 2. Steps to Creating a Customised IDOC
(see Appendix III for Screenshots of Steps)

2.1 Outbound Interface
PROCESS DIAGRAM
Outbound Interface
1. Analyse Hierarchy Levels
2. Create New segment
3. Create New IDoc Type
4. Create New Message Type
5. Link Message with IDoc Type
6. Create an entry in EDP13 via transactions WE20 and BD64
7. Populate the Custom IDoc via ABAP Program
7b Error Handling
7c. Send Status Email
8. Test the Population of the Custom IDoc

Step 1 – Analyse Hierarchy Levels:

Analyse the data relationships being processed in the interface. Define the appropriate hierarchical Parent-to-Child relationships.

Navigate to transaction code WEDI
Transaction WEDI displays the IDOC main menu. This allows navigation around the various development and control areas to create a customised IDOC.

Step 2 – Create a new segment:
via wedi : Development - IDOC Segments or Transaction code WE31.
· Enter segment name and click on Create.
Þ The name of the segment type must start with Z1[1], and have a maximum of eight characters.
· Enter description and enter the relevant field names and data elements.
Þ The segment should represent a structure in the program so for each field in the segment a field name and a data element must be defined.
· Save the segment and enter Person Responsible and Processing Person[2].
· Go to Edit and Set Release.[3]
· Repeat this procedure for each new Segment in the IDOC.

Step 3 – Create a new IDOC Type
via wedi Development - IDOC Types or Transaction WE30.
· Enter segment name (starting with Z), click on Basic Type and then Create.
· Create as new, enter Person Responsible and Processing Person[4] and enter description.
· On ‘Create Basic Type’ screen decide where segments should be inserted and go to Edit/Create Segment.
· Complete relevant fields in the Maintain Attributes screen:



· From the relevant segments created in Step 2 enter the Segment type and if mandatory segment.
· The Minimum and Maximum number of segments to be allowed in the sequence. (One minimum and one maximum if segment is mandatory).
· The Parent Segment and Hierarchy Level will be automatically created depending on where in the IDOC tree you decided to create that particular segment.
· Repeat this process for each segment needed in the IDOC type, deciding whether to add the next segments at the same level or as a ‘Child’.
· When IDOC created return to initial screen. Go to Edit and Set Release.
· Go to Transaction WE60 to view the IDoc Type you have created.

Step 4 – Create new Message Type
via wedi Development - Message Types or Transaction WE81.
· Display/Change and click on New Entries
· Create a new Message Type and Save.

Step 5 – Link Message Type to IDOC Type
via wedi Development - IDOC Type/Message or Transaction WE82.
· Display/Change and then click on New Entries.
· Enter Message Type, Basic Type (IDOC Type) and Release (46C) and Save.

Step 6 – Create an entry in EDP13 via transactions WE20 and BD64.
The partner profile for the Idoc must be set up and generated in the transaction BD64 and transaction WE20.
· WE20 – Add Message Type to appropriate Partner Type, Enter Message Type, Receiver Port and Idoc Type and Save.
· BD64 – Create a Model View, Enter Sender and Receiver Ports, Attach Message Type. Go to ‘Environment’ on Menu and click on Generate Partner Profiles and generate (not save) profile.

Step 7 – Populate the custom IDOC via ABAP Program
See Test Program ZOUTBD_IDOC_TEMPLATE, Appendix IV.
· Create an Internal Table for each segment type, this should be exactly the same structure as the segment type.
· The control record is filled into a structure like EDIDC. The message type and the Idoc type for the Idoc must be populated into the eddic structure.
- PERFORM populate_Control_structure USING c_mestyp
c_SEGMENT_type1.
· The data segments are filled into a structure like edidd-sdata; sdata and the segment name are populated into the edidd structure.
- PERFORM transfer_Parent_data_to_seg.
· The standard SAP function module MASTER_IDOC_DISTRIBUTE is called to pass the populated IDOC to the ALE Layer.
- PERFORM master_idoc_distribute.
· NOTE: This function module is only called for stand alone programs and Shared Master Data programs (SMD). It is not called when using extensions or output determination.
· The ALE Layer handles the sending of the IDOC to the receiving system.
· Error Handling (see Step 7b).
· Commit work.

Project Specific
Step 7b – Error Handling
· Analyse which fields in the interface are mandatory for the receiving system and who needs to receive error notification.
· Declare a structure of type ‘MCMAILOBJ’ for sending instructions.
· Enter values for the internal table based on structure ‘MCMAILOBJ’[5]
· For selection processes, on SY-SUBRC checks and where fields are mandatory for the receiving system; insert Function Module ‘MC_SEND_MAIL’.
· Enter values in the following parameters: -
MS_MAIL_SENDMODE = ‘B’ (Batch Mode)
MS_MAIL_TITLE = 'Mail Title'
MS_MAIL_DESCRIPTION = ‘Error description’ (e.g. MATNR not given)
MS_MAIL_RECEIVER = ‘Name of Receiver’ (To be determined)
MS_MAIL_EXPRESS = ‘E’ (Express Delivery)
MS_MAIL_DLINAME = Leave Blank
MS_MAIL_LANGU = 'E' (Language)
MS_MAIL_FUNKOBJ_NAME = Leave Blank

TABLES
MS_MAIL_CONT = I_MCMAILOBJ


Note:
It has to be determined separately for each interface how these errors and mail notifications are to be grouped – dependant upon the number of errors that are potentially likely. One possible approach is to send an email for each reason for rejection and include all the records that failed for that reason in the mail notification. Another possible approach is to send an email for every failure.
When error checking for mandatory fields it is common SAP practice to reject a record on its first failure (irrespective of subsequent errors in that record)
Step 7c – Send status mail
· Append to table I_MCMAILOBJ details of the time the interface was processed, how many Idocs were created and how many of these produced a status of 03.
· Select the user to receive the mail from ZINT_RECEIVER, using the name of the program as a key (SY-CPROG).
· Use function Module ‘MC_SEND_MAIL’ to send a mail to the user containing the contents of I_MCMAILOBJ at the end of the interface processing.

Step 8 – Test the population of the custom IDOC
via wedi IDoc - Display IDoc or Transaction WE02.
· Enter your message type and execute.
· Status should be green, double click on one of the Idocs you have created to view its contents.
· If a problem has occurred click on Status which will give you a description of the error.
· Drop down Data Records arrow and this should list the data in the IDoc in the correct hierarchical structure.
· Click on each individual segment and view the content to check that the correct data has been read.
· If you have UNIX access by using AL11 you can view the file that you have created.

Note:
For some interfaces it may be valid to send an empty file to SAP. This empty file is converted to the custom IDOC format expected by SAP. This custom IDOC will contain dummy information. In the inbound processing code, if the dummy information is identified then the processing of the IDOC is considered to be complete and the IDOC should then be assigned a successfully processed status of 53, even though it has not been processed at all.

2.2 Inbound Interface

Follow steps 1 to 5 inclusive as detailed above.

Step 6
Write a custom function module to handle custom inbound processing. This custom function module must
· Check for the correct message type
· Read the IDoc data segment
· Perform data conversion and validate the data as appropriate
· Post the data to the database
· Handle any error situations
· Set the correct return values for the status record

Note that the Function Module must not make a commit to the database. This is because the status record is not written until control returns to the ALE layer. So if you commit work in the Function Module and an error occurs in returning to the ALE Layer, the status record must not be updated with a successful outcome.

The commit work is executed in the ALE Layer after the status records are updated, via the standard SAP function module IDOC_INBOUND_PROCESS. This attributes of this function module are set up in (Transaction BD51), click on ‘New Entries’ and fill in data; the main input parameters being ‘Input Type’ and ‘Dialog Allowed’.
Take care as some standard SAP transactions contain a Commit Work as part of their processing. Therefore using a BDC to process inbound data to SAP may not be acceptable. You need to check that the SAP transaction is ALE enabled.

Step 7
(Transaction WE37)
Assign the custom function module to the IDoc type and the message type.
Set function module to type ‘F’ and direction ‘2’ for inbound.

Step 8
(Transaction WE42)
Create a new process code and assign it to the function module. The process code determines how the incoming IDoc is to be processed in SAP.

Step 9
(Transaction BD67)
Assign the function module to the process code created above. Got to ‘New Entries’ and enter the process code and the function module name.
Step 10
(Transaction WE20 and Transaction BD64)
Create a partner profile for your message and ensure that in transaction WE20 the process code is the one that points to your function module. (See step 6 of creating Outbound Idocs).

Step 11
Ensure that error handling functionality is present.

Note:

If an interface is expecting a file every day, and a custom IDoc may only be output from SAP periodically, it would be necessary to create some kind of output from SAP on a daily basis to pass to Mercator to allow it to map to an empty file. As we are dealing with custom IDoc types we can design the IDoc so that the data segments are not mandatory. Therefore the SAP program, on finding no data to populate the custom IDoc, would only need to create the control record. The empty IDoc containing the control record would be passed to Mercator. Mercator will map this to an empty file format.

Useful Transaction Codes:

WEDI : IDoc Menu

WE02 : IDoc List (can enter IDoc number to select on)

WE05 : IDoc List

WE19 : Transaction WE19 can be used to test the IDoc

WE30 : IDoc Type Development: Initial Screen

WE31: Development Segments: Initial Screen

WE60 : Documentation for IDoc Types. This allows you to view the IDoc you have created.

WE81 : Display View ‘EDI: Logical Message Types’: Overview

WE82: Display View ‘Message Types and Assignment to IDoc Types’: Overview