DELOITTE CONSULTING PRIVATE LIMITED

CONSULTING - SAP

IDOC – Intermediate Document

1

CONTENTS:

Top of the Document

1. INTRODUCTION:...................................................................................................................... 3

1.1. Outbound Processing of IDocs.............................................................................................................................................41.1.1. Creation of Segments: WE31.............................................................................................................................................41.1.2. Creation of IDOC Type: WE30........................................................................................................................................13

1.1.2.1. IDOC – Insight into the instance of Idoc Type.......................................................................................................181.1.3. Creation of Message Types: WE81..................................................................................................................................18

1.1.3.1. Linking the Message Type and IDoc Type: WE82.................................................................................................221.1.4. Creation of PORTS: WE21..............................................................................................................................................261.1.5. Creation of Partner Profiles: WE20..................................................................................................................................311.1.6. Program to create IDocs:..................................................................................................................................................371.1.7. Track of outbound idocs: WE02 / WE05.........................................................................................................................381.1.8. Additional Information on the outbound side of an IDoc.................................................................................................38

1.2. Inbound Processing of IDocs..............................................................................................................................................391.2.1. Initial Steps:......................................................................................................................................................................391.2.2. Creation of Inbound Function Module:............................................................................................................................391.2.3. Registering the inbound FM: BD51.................................................................................................................................401.2.4. Assignment of Function Module to Logical Message and Idoc Type: WE57.................................................................421.2.5. Maintenance of Inbound Process Code: WE42................................................................................................................451.2.6. Maintenance of inbound partner profile: WE20...............................................................................................................551.2.7. Effect of inbound settings, when an idoc is received from the sending system...............................................................601.2.8. Some additional points for the inbound process...............................................................................................................61

1.2.8.1. PORT Maintenance on inbound side: (Transaction: WE20)..................................................................................611.2.8.2. How to know whether an idoc has been posted successfully in the inbound system?............................................611.2.8.3. Are all the settings that have been explained above are needed for the inbound processing?................................61

1.3. Additional Points.................................................................................................................................................................611.3.1. List of outbound transactions used in this document........................................................................................................621.3.2. List if inbound transactions used in this document..........................................................................................................62

2. ADDITIONAL INFORMATION - APPENDIX...........................................................................62

2.1. Appendix 1: Creating/Maintaining RFC Connection......................................................................................................62

2.2. Appendix 2: Testing of the scenario explained from EC6 system to P47 system..........................................................65

2.3. Appendix 3: Bonus Feature – Adding an image to the SAP Logon screen..........................................................................76

2

1. Introduction:

What is this document all about?

This document shows the IDOC development from basics, with out getting into too many technical jargons. A fresh development is considered and detailed screen shots are provided.

What additional features this document has apart from the other documents?

A complete working solution with a test run is provided. Moreover the solution is from the sand box systems giving the reader the flexibility of practicing while going through this document.

The example that is being talked in here is between the two Deloitte sandbox systems namely, EC6 Client 950 and P47 System Client 321. Technically detailed screen-shots are provided for creation of the complete inbound & outbound idoc processing.

What is the main aim in this document? (Problem described and solved in this document)

There is a DB table: ZPRG_STUD (custom table) in both EC6 and P47 system with the same fields. There is a program in EC6 system that inserts an entry into this DB Table. The problem is to update the same DB Table in the P47 system using IDOC procedure with the same program. Iterating the problem: Whenever there is an insertion of an entry into DB table: ZPRG_STUD in EC6 system by this program the same entry should be inserted in P47 system DB Table using the IDOCs.

How does this example map to a real world scenario?

In the real world it may not be required to deal with the complete outbound & inbound cycle. If there is an overall view about the basics providing a solution would become easier. This document plainly tries to give an in-depth view about the basics.

3

The table fields are shown: This contains fields with currency, date and time. The same fields are maintained in both the systems.

1.1. Outbound Processing of IDocs

Creation of Segments: WE31

What is a Segment?

The segments are the basic building structures of an IDoc. The segment types arranged in the hierarchy define the structure of an IDoc Type. The segments define the fields that an IDoc holds.

The SEGMENT Name starts with "Y1" or "Z1". The Segment Type is RELEASE Independent name of the Segment. The name of the segment type remains the same irrespective of the release of the R/3 system.

The segment consists of segment fields which are basic building blocks of an IDOC Type.

Transaction: WE31 is used for the creation of new segment types.

What is Segment Definition?

Whenever a Segment Type is SAVED a Segment Definition is created with the concatenation of Segment Type and the Release. (The segment definition is created automatically by the system)

4

The segment definition is generally created with the first two characters “Y2” or “Z2”. The Segment Definition PLAYS a Key Role, especially if two R/3 Systems of different releases are talking using IDoc.

To understand the difference between Segment Type and Segment Definition, let us take an example of the standard Segment Type: E1BPE1MATHEAD

Creating a new segment type in the EC6 system:

Go to the transaction WE31:

Enter a segment type: Y1PRG_STUID, in the initial screen of transaction WE31. Observe all the fields in the segment having the CHAR data type. Even the Currency, Date and Time are CHAR fields. The data is transferred between the two R/3 systems in the form of a data string.

5

Initial Screen of Transaction: WE31 – Development Segments

Click on the create button in the application tool bar.

We might encounter a Pop-up if the length of the segment name is greater than 7 characters. This is because for sap systems less than or equal to version 4.0 the name of the segments cannot exceed 7 characters. If one of the sap systems involved is system below version 4.0 then we need to take care of this. (Read long text of

this message by clicking on this on the pop-up.)

In this case no system involved deals with those versions of sap. Go ahead and click ENTER.

6

Next screen: Enter the short description and segment fields.

7

Maintain all the segment fields as character fields because the transfer of data happens in the form of a string.

Once all the fields have been added, click on the SAVE button. (This asks for a package – as this is a test this has been stored in $TMP package)

Hit ENTER.

8

The next screen: The same screen when the Hat like button is clicked in the application tool bar. It shows the Header data.

The above screen gives full information of the segment type. Observe the yellow icon which means the segment has not yet been released.

9

Click on back button to reach the initial screen of WE31.

Next step is to release the segment: This is an important step, with out doing this we cannot have the Idoc sent to other systems.

10

To release a Segment:

On the initial screen of WE31, choose Edit Set Release.

11

After releasing the segment type:

Notice the release flag check box in the table control. It would be marked.

Click on the check button:

Log should look like this, which means that this segment type can be used in an Idoc type, which can be used to transfer the data.

Once a segment has been changed, try to change the segment observe the flow. The system will not allow changing the segment anymore.

12

Released segment cannot be changed. To change the released segments we need to first cancel the release. This option has been left for the curious reader to explore as an exercise!

Creation of IDOC Type: WE30

IDOC Type: No doubt the segment types are the basic building blocks of an IDoc Type. An IDoc Type has the segment types arranged in the hierarchical manner as per the business requirements. If the segments are related to each other, they are arranged in the hierarchical manner. For simplicity in this case there is only one segment type in the IDoc Type.

IDoc: IDoc is an instance of an IDoc Type. An IDoc Type filled with data is called an IDoc. Idocs are transferred from one system to another.

(In ABAP Objects version Idoc Type can be compared to the Class Definition and Idoc to the Instance of the class)

The data that is filled in the IDoc follow the structure of the corresponding IDoc Type (Hierarchical segment structure).

Transaction: WE30 is used to create new IDoc Types or Extend existing IDoc Types.

Select the radio-button Basic Type. Click on create button.

13

In this case a new IDoc type is created.

While creating a new idoc type a pop-up may be thrown regarding the length of the Idoc Type name. Next screen of WE30: Actual Idoc Type creation screen

14

Procedure to add segments to an Idoc Type:

1. Put the cursor on the idoc type

2. click on the create button in the application tool bar3. A small screen is thrown asking for the segment details

4. Enter the segment type created in WE30a. Specify if it a mandatory segment. It means at least one field of this segment type should have

been filled when an idoc is created.b. Specify the minimum and maximum number of times this segment has to occur.

i. The header segment would be filled once and it is mandatory so the minimum and maximum values would be one.

ii. In case of items, they can be many so the minimum number would be one and the maximum number would be 9999 depending on the case.

iii. If a segment is not marked mandatory – irrespective of the minimum number the segment need not filled in the idoc.

c. The parent segment and the hierarchy level would be filled automatically.5. In this case the segment is a mandatory segment with maximum and minimum values one.

15

Click on HAT button: This gives the header data for the idoc type

Click back and get to the initial screen of WE30.

16

Release the IDOC Type also.

Edit Set Release

Next a pop-up with some information: Even though the default is NO – as usual go ahead and click YES.

It is a message to warn that released idoc types cannot be changed. Even if you want to change after release, just cancel the release. To cancel the release (check the screen where we released carefully), Edit Cancel release would do it.

Click yes; following information message is thrown hit ENTER.

17

You can click on the check button to see the status of idoc type.

1.1.2.1. IDOC – Insight into the instance of Idoc Type.

Idoc is defined as an instance of Idoc Type. Idoc Type will have only segments defined in it in a particular hierarchical sequence. It just defines the structure. As such Idoc Type cannot hold any data on its own. It is the Idoc that actually consists of data. Hence an idoc is referred to an instance of idoc type. Apart from holding the data, Idoc will also have the following data associated with it.

Control Record data: From which system to which system is the data flowing i.e., the sending system and the receiving system information along with the message type to which it belongs to. This is built by the sending system, with the necessary information of sending system, receiving system and the message type. The control record data is stored in the DB Table: EDIDC.

Status record data: Each Idoc is associated with different statuses depending on its movement from sending system to receiving system. This is automatically generated by the system based on the status and progress of an idoc. The status record data is stored in the data table: EDIDS.

Outbound idocs are associated with statuses from 01 to 49. Status 03 is success.Inbound idocs are associated with statuses 50 and above 50. Status 53 is success.

Data record: This is the main part which carries the actual data. In our case the student data is carried in this part. The data record is also built in the sending system. The data record is stored in the DB Table: EDIDD.

In practical world the usage of these terms: IDOC and IDOC Type are not followed strictly and in general the word idoc is used to refer to both the idoc type and idoc.

Creation of Message Types: WE81

Message Type defines the business significance of an IDoc Type. The Message Type that is associated to an Idoc Type is used for the talk between two systems. One IDoc Type can be assigned to many Message Types. The two systems talk to each other using the message type. The same IDoc Type can be used for different business requirements. For each business requirement the same IDoc Type is assigned to different Message Types.

Example: Consider the receiving P47 system. Say, for the same IDOC Type – IDocs are sent by the EC6 system to the P47 system but from different triggering points

Case 1: IDocs are received from EC6 system by a program, the DB table: ZPRG_STUD should get updated

Case 2: IDocs are also received from some other point then a workflow needs to be triggered in the P47 system

In both cases the sending, receiving and the IDoc Type are same. But the action that needs to take place is different. These two cases are differentiated by associating the same idoc type to two different message

18

types. Depending on the Message Type, the case 1 or case 2 is differentiated and the further action is taken in the receiving system.

This is the reason why the same IDoc Type can be associated with different Message Types.

The Message Types are created using the transaction: WE81. These are maintained in the DB Table: EDMSG, under the Maintenance View: VEDI_EDMSG.

Transaction: WE81

Click on change: This message is to say that a cross-client table is being maintained. Cross-client tables are tables with out the client (MANDT) field.

19

On click of New Entries:

20

Enter the message type along with a description.

All cross-client table entries need to be saved under a workbench request. There would be pop-up asking you to enter a workbench request. The specification of the request is mandatory, create one workbench request and assign the entry to that request.

The pop-up for the workbench request.

Specify an appropriate workbench request.

21

Display of the entry created just now.

1.1.3.1. Linking the Message Type and IDoc Type: WE82

Till now the New Basic IDoc Type and Message Type are created, it is time to link the two. The two are linked by an entry in the DB Table: EDIMSG. The transaction used for this is WE82.

Transaction: WE82 – one more cross client table needs to be maintained.

22

Initial screen of transaction: WE82

Click on the change button accept all the pop-us (information messages)

23

Change mode of WE82:

The release column specifies: Release for which the message type assignment is valid.

24

Insert an entry:

After insertion click on the save button. This would again prompt for a work bench request.

25

Display of WE82 once an entry has been maintained:

Creation of PORTS: WE21

It is a channel used by the sending SAP System to communicate with the external systems. External Systems can be another R/3 system or R/2 system or non-sap system.

Depending on the external system type the port type also varies. In this case another SAP R/3 system is the receiving system. Create a tRFC (Transactional RFC) port.

If EDI Sub-system is the external system then port type “FILE” is used.

26

WE21: PORT Creation – Initial screen of PORT Creation:

Different types of ports are used for talking to different types of external systems.

To talk to an SAP system use a tRFC port (Transactional RFC Port) similarly to talk to an external EDI Subsystem use a port of type FILE.

27

Put the cursor on the Transactional RFC and click on create.

Next screens

Whether it is required to use a own port name or let the system generate one

28

Own port name has been used for easy identification.

Next screen:

Here in the RFC Destination field we can specify only those values that are maintained using the transaction SM59. Check the appendix 1 for this.

29

The version of the receiving system to which the communication is being made, has to be specified correctly. If the system that is being communicated has version less than 4, the first radio-button has to be selected at the same time the control record applicable to that version has to be used. In addition to this to accommodate the length of segment, idoc type names etc, conversion tables have to be maintained in customizing. (This situation is out of scope of this document.)

SAVE the entry for the port maintenance:

Display of the same after creation:

30

Creation of Partner Profiles: WE20

This is one of the important steps in communication with IDocs. The partner profiles can be used to find with which external systems a system can communicate. Unless an entry is maintained in partner profile for an external system, this system cannot communicate with that external system. While maintaining the partner profiles the message types are used and not the idoc types directly.

In short if a system wants to send particular IDocs to another external system. Get the necessary message type and maintain an entry for that external system with this message type. Then this system can send the idocs of that particular message type.

WE20: Partner Profiles: Initial screen. As is the case with ports, there are different types of partner profiles for different types of receiving systems. As the receiving system is an R/3 system. The partner profile type is LS: Logical System.

31

Select the partner profile LS and click on create button.

32

On the next screen enter:1. Partner No: P47CLNT321.2. Partner Type: LS (Logical System)3. Under the tab page: Post Processing: permitted agent

a. Type: P – Personb. Agent: User Namec. Language: EN

33

After maintenance it looks like this:

The EC6 system is the sending system i.e., the outbound system, hence the entry for the message type needs to be maintained under the outbound parameters table control.

Click on the Insert Button at the bottom – and the initial screen would look like this:

34

After entering the following data hit ENTER key once

35

Sub-systems are not present in this case. The two R/3 systems communicate with each other directly without any sub-system in-between.

The screen would change like this. The radio buttons for sub-system will vanish as the systems involved are R/3 SAP Systems and no sub-systems are involved.

36

Once all the above settings are completed, the entry would look like this on the initial screen.

37

Program to create IDocs:

This program uses the function module: MASTER_IDOC_DISTRIBUTE, to send the idocs out of the sending system.

Important points to be noted in the program:1. Filling of the status record2. Usage of the FM: MASTER_IDOC_DISTRIBUTE3. Usage of the FM: DEQUEUE_ALL and explicit COMMIT WORK AND WAIT statements to force

any outbound idoc in status 30 to status 03.

Code for the direct outbound triggering program:

Note: The source code is attached as a .rar file which can be opened in a word pad.

Track of outbound idocs: WE02 / WE05

38

The transactions WE02 or WE05 can be used to find the status of an IDoc.

For the outbound idocs the statuses 01 to 49 are valid i.e., for any outbound idoc there can be no status above 49 or below 01.

30 is the ready status that the idoc is fine and 03 is the success state. Once an idoc reaches state 03 it means the sending system has successfully send the idoc data out of the sending system. This does not convey that the receiving system has successfully received it. The status 03 means the sending system is successful in sending the data out. Once an idoc reaches the 03 status as far as the outbound side of an idoc is considered, it is completed.

Check appendix 2 for further details.

Additional Information on the outbound side of an IDoc

What are the different outbound processing of IDocs?

There are two different processing of outbound IDocs1. Direct processing: This is what has been discussed till now2. Message Control: IDocs are triggered from an application. For this the necessary customizing needs

to be done in the transaction: NACE. At present this method is out of scope of this document.

When we are sending mass idocs from the sending system to the receiving system most of the outbound idocs are ending up in status 30 (yellow)

This is the most commonly faced problem during outbound processing of idocs. After processing all the outbound idocs use the FM: “DEQUEUE_ALL” and then use the explicit COMMIT WORK (or COMMIT WORK AND WAIT) statement. This would send the idocs to status 03. This resolves all the locking and database issues and sends the outbound idocs from status 30 to status 03.

If I can send idocs from EC6 system to P47 system, does it mean I can send idocs from P47 system to EC6 system?

If EC6 system can send idocs to P47 system, the necessary customizing has been done in SM59 for EC6 to understand the connection of P47. As well the ports have been defined. Unless we make the P47 system understand the EC6 as the partner using SM59 and a port has been created (at the least if these settings are maintained) we cannot assure the movement from P47 to EC6. In short the answer is one-way ticket.

Can we be assured that the idocs have been posted in the receiving system safely once the outbound idocs are in status 03 in the sending system?

No, this cannot be assured. But yes the idocs have moved out of the sending system safely. The receiving system might/might not have received the idocs. But posting of idocs in the receiving system definitely cannot be guaranteed.

Why this document did not explain the creation of process code on the outbound side.

39

In this document we are not looking at the outbound process using message control where-in the transaction NACE is used. We are looking at the direct outbound processing, hence we did not discuss about the process codes on the outbound side. We need to have the understanding of message control and how an output type is determined for this. If possible we shall have one more exclusive document for the same.

Do you know: irrespective the namespace of the project all lock objects that are created using transaction SE11 start with the alphabet “E”!

Only half of the idoc journey is completed till now. Let us take a look at the other half which is still more interesting the inbound processing of Idocs.

1.2. Inbound Processing of IDocs

The Segment Types, IDoc Types, Message Types and the linkage between the IDoc Type and the Segment Type are carried the same way as has been done on the outbound side.

Initial Steps:

The minimum basic requirement for the inbound system to identify the sending system idoc is that both the systems should have the same name for the:

1. Segment type (Transaction: WE31) - Y1PRG_STUID2. Idoc Type (Transaction: WE30) - 3. Message Type (Transaction: WE81) and4. Linkage between the Idoc Type and Message Type. (Transaction: WE82)

Refer to the above outbound idoc section for the creation.

Note: Maintain the same names for the above 3 values in both the EC6 and P47 system. If you don’t, anyway you will end up doing it as the idocs will not get posted in the receiving system.

Creation of Inbound Function Module:

This is one of the most crucial steps in the inbound processing. This is the code that gets executed at the end to post the idocs in the receiving system.

Create a Function Module (FM) for the inbound processing of idocs. Once the idocs are received by the receiving system, the data that is received in the data records (an idoc consists of Status, Control & Data records) is analyzed and posted using the function module. Technically if all the settings that are explained from now on are correct in the receiving system, it is the code in this FM that processes the idocs.

All the inbound function modules that are created in the system will have a pre-defined standard interface. One should not deviate from this standard interface. This is mandatory; else we might end up with an entry in ST22 transaction (dump in the receiving system).

Function Group: ZPRG_IDOC_INBOUND_FGFunction Module: ZPRG_INBOUND_IDOC_STUID_INS

Interface of the inbound idoc function module:

40

Importing Parameters:

Parameter Name Type / Like Associated TypeINPUT_METHOD LIKE BDWFAP_PAR-INPUTMETHDMASS_PROCESSING LIKE BDWFAP_PAR-MASS_PROC

Exporting Parameters:

Parameter Name Type / Like Associated TypeWORKFLOW_RESULT LIKE BDWF_PARAM-RESULTAPPLICATION_VARIABLE LIKE BDWF_PARAM-APPL_VARIN_UPDATE_TASK LIKE BDWFAP_PAR-UPDATETASKCALL_TRANSACTION_DONE LIKE BDWFAP_PAR-CALLTRANS

Tables:

Parameter Name Type / Like Associated TypeIDOC_CONTRL LIKE EDIDCIDOC_DATA LIKE EDIDDIDOC_STATUS LIKE BDIDOCSTATRETURN_VARIABLES LIKE BDWFRETVARSERIALIZATION_INFO LIKE BDI_SER

Exceptions:

Name DescriptionWRONG_FUNCTION_CALLED Wrong FM has been called

Code in function module: (.rtf extension file - needs word pad to open)

Note: Do not use the any other naming convention for the function module interface parameters.

At this point only creation and activation of the function module is required. Coding of the function module can be done once all other settings are completed. Registering the inbound FM: BD51

This is an entry in the cross client DB Table: TBD51, which is maintained with the view: V_TBD51.

This entry in this table registers the function module as Inbound Idoc Posting function module. Registry of a function module is mandatory before using it for the inbound processing of idocs.Initial screen of Transaction: BD51 – Characteristics of Inbound Function Module

41

Make a new entry in this DB Table with the name of the Function Module that has been created above.

Function Module (Inbound): ZPRG_INBOUND_IDOC_STUID_INSInput Type: 0 – Mass ProcessingDialog Allowed: do not check the check box.

After entry:

42

Assignment of Function Module to Logical Message and Idoc Type: WE57

In this step the Function Module is attached to the Idoc Type and the message type that has been created above.

This is also an entry into the cross-client table: EDIFCT which is maintained by the view: VEDIEDIFCT.

As this is a cross-client entry it would ask for a workbench request, when you are saving the entry. Save it in an appropriate workbench request.

Initial screen of WE57: Assignment of FM to idoc type and message type

Click on the change button and click on new entries.

Screen when New Entries button is clicked:

43

Maintain the entries in this screen with the Function Module name created, Idoc Type and message type.

The type field should be filled with “F: Function Module” as the inbound processing of idocs is done by the function module.

The direction is “2: Inbound” for the inbound processing.

Screen-shot with values filled:

44

While saving it would ask for a workbench request. Save it in an appropriate workbench request.

Once saved the entry would look like this:

45

Maintenance of Inbound Process Code: WE42

In this step the function module that has been created is associated with the process code. Process code is one more name of a specific process, for example a function module or workflow. Idocs are written using this process.

Process/Identification here means either a function module or a workflow.

The processing which reads the idoc data and generates the corresponding documents is found using the inbound process code. Inbound process code is associated with a function module or a workflow. Once an idoc is received in the receiving system it is the link between process code and the processing that decides which processing (whether function module or workflow) that needs to be called. One process code is associated to either a function module or a workflow but not both.

Initial screen of transaction: WE42

46

Click on Change button:

New Entries: The screen is open for input.

47

Enter a new inbound process code name and description.

48

As of now do not maintain anything in identification field, under the processing type select the radio-button “Processing by function-module”.

Click on save.

It would prompt for a customizing request save it in an appropriate customizing request.

(As this is a client-dependent entry this prompts for a customizing request).

Once the above steps are completed the screen for process codes would look like this:

49

Click on the button which is towards the right of Identification Field:50

The screen that appears now

For the function module field it is a drop-down list, any function module that has been created in SE37 cannot be maintained. Select the function module that has been created from the drop-down.

Note: If the function module that has been created could not be found then check if the function module has been registered using the transaction: BD51. Check the steps above to register the function module using BD51.

Select the function module from the drop-down.

51

Give the object type as IDOCAPPL. Do not maintain any start event.

Save the entry. (It would prompt for a customizing request)

52

Click on the back button:

Click on the back button

53

The next screen:

Now double-click on the logical message on the left side of the above pane. The following screen would appear

54

Click on New Entries: The following screen would be opened for input

Give the name of message type.

55

Click on SAVE button again.

Note: The navigation of screens while maintaining entries in WE42 may slightly vary.

With this step the process code has been given identification and linked to a message type i.e., if an idoc is received of this message type then this process code is called which then triggers the identification associated with it. (The identification/processing associated in this case is the Function Module)

Maintenance of inbound partner profile: WE20

For the inbound system to identify the sending system this setting needs to be maintained on the inbound side. Even though the transaction for partner profiles on the outbound and inbound is same, the way they are maintained is different.

WE20: Partner Profile.

56

Select the partner type: LS Logical system.

Select the partner EC6CLNT950 (This has been already created – This is the sending system)

Click on the Insert Button on the Inbound Parameters side.

Next screen when the insert button is selected:

57

Maintain the following fields:

58

Message Type: Created in WE82Process Code: Created in WE42

And say Trigger Immediately

Hit Enter:

59

Save the entries.

Double-click on the process code to navigate to the identification maintained and the message type associated with it.

After maintenance of above settings the screen of WE20 would look like this:

60

This completes the idoc inbound settings.

Effect of inbound settings, when an idoc is received from the sending system

When an idoc is sent by a sending system to a receiving system, the following steps are carried by the receiving system:

Step 1: The receiving system checks whether the sending system is a partner. This is maintained in the partner profiles. If the sending system is not identified as the partner, even though the idocs are received they will be put into error. Hence the maintenance of sending system as a partner in WE20 is important.

Step 2: Once the sending system is identified as the partner. Then the idoc is checked for the message type from the control record. Again the partner profiles are checked whether for the sending system the message type that has been received can be accepted or not. (All these accepted message types are maintained in the inbound parameters section of the partner profiles). If the corresponding message type is not maintained in the inbound parameters of the partner profiles then the idocs are not accepted and they are all thrown into error status.

Step 3: If the message type is also a valid message type, the process code associated with the message type is called. (This is maintained in WE20 and WE42).

Step 4: The process code looks for the identification associated with it (whether it is a workflow or a function module) depending on that the corresponding call to the associated identification will be made. In this case it is the function module that is called and the code of the function module is executed.

61

Some additional points for the inbound process

1.2.8.1. PORT Maintenance on inbound side: (Transaction: WE20)

Not required for the receiving side. Port is a channel using which the system sends the data.

While maintaining the port on the outbound side, the receiving system name as created in RFC Connections (Transaction: SM59) is mentioned. The sending system uses that channel to pass the idocs to the receiving system. This is the reason why the partner profiles while maintaining on the inbound side do not ask for the port.

1.2.8.2. How to know whether an idoc has been posted successfully in the inbound system?

Check the transaction: BD87 in the receiving system. On the initial screen at least specify the message type for faster processing. Once the transaction BD87 is executed the statuses of idocs based on message type can be seen. Status 53 of an inbound idoc is the final success state.

1.2.8.3. Are all the settings that have been explained above are needed for the inbound processing?

Yes. The settings that are explained in this document are the most basic inbound settings that are required for the successful inbound processing.

Apart from these, setting of the RFC Connection - transaction SM59 is very important, which has been shown in appendix.

1.3. Additional Points

Are there any other transactions/processes apart from those specified in this document?

Simple answer is YES. Idoc is a big ocean and one document cannot cover it fully. The approach of this document is to give the reader basic idea of settings that are required with out getting into too many technical jargons. This document tries to plainly explain the settings with extensive screen shots.

Some points which have not been covered which the reader can explore:

1. The transaction: WE19 which is an idoc testing transaction and is used a lot by the idoc developers is not covered in this document. Like wise there are many others. But once the reader gets the basic idea on the complete outbound and inbound cycle it is left for the reader to explore further options.

2. Transaction: SALE, which is a one stop for maintaining all the idoc settings. (Going through this transaction will let you know that this document covers nothing!!!)

3. What has been discussed in this document is only the ALE (Application Link Enabling) scenario, wherein the sending and receiving systems both are SAP systems. There is one more EDI (Electronic Data Interchange) scenario which is a talk between an SAP system and a non-sap system. This uses port type file.

62

List of outbound transactions used in this document

SI.No. Transaction Purpose1 WE31 Creation of New Segment Types2 WE30 Creation of New IDoc Types3 WE81 Creation of New Message Type4 WE82 Assigning the Message Type to IDoc Type5 WE21 Port Creation6 WE20 Partner Profile Creation7 WE02 /

WE05List of Idocs generated.

8 SM59 To Maintain RFC Connection to the receiving system.

List if inbound transactions used in this document

SI.No. Transaction Purpose1 WE31 Creation of New Segment Types2 WE30 Creation of New IDoc Types3 WE81 Creation of New Message Type4 WE82 Assigning the Message Type to IDoc Type5 SE37 Creation of New Function Group and Function Module6 BD51 Registering the Function Module as a Inbound Function7 WE57 Assigning the Inbound Function Module to the Message Type and the

IDoc Type8 WE42 Creation & Maintenance of Inbound Process Code9 WE20 Maintaining Partner Profile on the Inbound Side

Do you know: Double click on a field of any DB Table a small screen would be opened up with all the details of that field. Instead of assigning search help at the data element level and affect all the fields associated with that data element, search help can be assigned here with out disturbing the data element. Search help attached at this level will be called and not search help attached at data element level.

2. Additional Information - Appendix

2.1. Appendix 1: Creating/Maintaining RFC Connection (Only for understanding)RFC Connections between the sending and receiving systems play a very vital role while transferring data between two R/3 systems.

We take a look at maintaining the RFC Connection between P47 and EC6. In our case the source system is EC6 system and the target system is P47 system. From the EC6 system we are trying to maintain the login to P47 system. As the link is between two R/3 systems – the RFC Connection Type is 3: ABAP Connection.

Target System Screen shot – The system to which the user is interested to Login. (In our case it is P47 system.)

63

This is obtained by System Settings in the Target system.

In the Transaction SM59 to maintain a system as RFC Destination: This is screen shot from the EC6 system. The target host value from the above screen is taken and filled into same field in below and hit ENTER once. At the same time maintain the system number too. (Same system number that is given in logon pad).

64

Logon & Security Tab page: Give the user name and the password. Generally the WF-BATCH user is used. But in this my user-id and password of P47 system have been used. The language and client fields are also required. Any small change or non-maintenance of a setting here would drastically affect the movement of Idoc from one system to another. This setting of SM59 plays a major role for two SAP Systems to talk to each other.

65

Screen shot from DB Table: RFCDES. All the RFC Destinations that are created using transaction SM59 are maintained in this database table.

Once the RFC Destination is saved in the Transaction: SM59, Check the entry created in DB Table: RFCDES

This does not mean once can directly maintain an entry in RFCDES table!!!

2.2. Appendix 2: Testing of the scenario explained from EC6 system to P47 system

Let us carry this journey and run a test case which involves both the EC6 (Sending System) and P47 (Receiving System).

Initial state of DB Table: ZPRG_STUD in the P47 system

Receiving system: P47

Entries in DB Table: ZPRG_STUD.

The number of entries is zero.

Let us try to insert an entry with Student ID (STUID): 204 from the system EC6 using the idoc approach.

66

Screen Shot: Before starting the process P47 System.

67

Sending System: EC6 DB Table: ZPRG_STUD status of entries

68

There is no entry with STUID = 204 even in the sending system.Let us execute the program: ZPRG_STUID_OUTBOUND_IDOC in the sending EC6 system.

For the student id (STUID): 204 and Class: 04.

Output of report: (This report code has been attached in the RTF file under the outbound section)

69

The entry with STUID = 204 (marked in RED) has been inserted.

Let’s check WE02 – (Give at least a part of the Basic Type with wild character)

70

This is our IDOC – Check the content of data records. The Data Record corresponds to the structure of segment type.

This left part of the screen shows the different parts of an idoc (This is the instance of the idoc type) Idoc has the

1. Control Record (Check the next screen shot for it’s values) this has been filled by the program2. Data Record – Filled in our program. Carries the actual data and3. Status Records – These are the different states and statuses that this idoc has under gone through. All

these statuses are set by the system.

Finally Status = 03 means that the idoc has got passed successfully from the sending system.

71

Just take a look at the control record: the partner tab is shown for the information. This has been filled by the direct outbound program.

With this status of the outbound idoc 03 – Data passed to port; the sending system has successfully sent the idoc to the port from where the role of the receiving starts.

Let’s get back to the receiving P47 system:

72

Transaction: BD87: Transaction used for looking at Inbound Idocs. (At least specify part of message type)

And execute (F8):

73

The message marked in yellow has come from the inbound Function Module. The status record message has been shown.

Click on Display IDocs button in the application toolbar:

This is the inbound Idoc

The data record has the same content!!! This is what we wanted to between the systems.

The idoc has the same structure as on the outbound side i.e., it has Control, Data and Status Records.

Take a look at the status records. It has gone through various states most of which have been assigned by the system. Except for the status 53 which has been by the Inbound Function Module (this status is assigned when the insertion into the DB Table: ZPRG_STUD is successful. If this insertion was not successful the status would have been 51 with RED traffic light).

74

Control Record:

Take a look at the entries: In the Recipient Information – The port name is not same in the sending system and the receiving system.

This PORT: P47CLNT321 has been created in the sending system and the sending system has sent the data to the receiving system using that channel. Once the data is received by that port the receiving system starts reacting to the received data. The receiving system has no idea of the port used by the sending system except that the sending system can send data to it; this setting has been made in the transaction SM59. The receiving system uses the default port information for both the sending and receiving system.

In short, the port created in the sending system is used by the sending system to send the data to the port. The receiving system will not be aware of the channel used by the sending system except that whether the data from the sending system can be accepted or not. Still, if this point is not clear and you want some more light on this point, keep this document closer to light and read!

75

With the status 53 (GREEN traffic light) we can be sure that the journey in the receiving went fine.

To satisfy the thirst of the reader let me take you through the DB table: ZPRG_STUD in the receiving system P47 again.

76

Execute to look at the entry:

2.3. Appendix 3: Bonus Feature – Adding an image to the SAP Logon screen.

This is not related to the idoc processing. This is an added feature for going through this document. The main aim of this exercise is to add a BMP file to the SAP Easy Access screen. Let us add the rising sun logo in the SAP Logon screen.

Store this image as a BMP file in the presentation server (on your desktop).

77

Call the transaction: SMW0 – Initial screen of transaction.

78

Execute the next screen:

The screen on execution:

Click on create button.

79

The screen for screen upload is opened

Obj. Name: Z_PICTURE_RAISING_SUNDescription: Raising Sun to be put on Initial Screen.

Enter the data:

Click on Import button.

80

Choose the path for the BMP file from the desktop/presentation server.

Assign a package: ($TMP for instance to save it as a local object)

81

After completing the above steps the Entry in transaction: SMW0.

Update the DB Table: SSM_CUST with ID: START_IMAGE, with the image just uploaded.

82

Initial status of DB Table: SSM_CUST

After running a small Z<program> with the update statement:

83

New Values:

Logoff from the SAP system and login again for the changes to take effect

The start image has got changed, with the one that has been uploaded and updated in SSM_CUST.

84

Your valuable feedback and suggestions for improvement can be directed to author at: rpasapula@deloitte.com

Disclaimer: This document does not hold any copyrights as such. This document uses the screen shots from the Deloitte sand box systems P47 and EC6 and is intended only for informational purposes. Neither the company nor the author of this document is responsible for any damage caused because of the settings explained in this document. The code is only intended to explain better and visualize the syntax and phrasing rules of certain coding. Author does not warrant the correctness and completeness of the code given herein, and shall not be liable for errors or damages caused by the usage of the Code. Legal actions of any sort are not entertained.

85