Professional Documents
Culture Documents
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.
The table fields are shown: This contains fields with currency, date and time. The same fields are maintained in both the systems.
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.
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.
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 this has been stored in $TMP package)
Hit ENTER.
The next screen: The same screen when the Hat shows the Header data.
The above screen gives full information of the segment type. Observe the yellow icon segment has not yet been released.
Click on back
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
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. 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! 12
13
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 bar 3. A small screen is thrown asking for the segment details
4. Enter the segment type created in WE30 a. 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
16
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.
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
20
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.
21
22
Click on the change button accept all the pop-us (information messages)
23
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
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.
Next screens Whether it is required to use a own port name or let the system generate one
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. 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: 29
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.
2. Partner Type: LS (Logical System) 3. Under the tab page: Post Processing: permitted agent a. Type: P Person b. Agent: User Name c. Language: EN
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. 33
Button at the bottom and the initial screen would look like this:
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. 35
Once all the above settings are completed, the entry would look like this on the initial screen. 36
Note: The source code is attached as a .rar file which can be opened in a word pad.
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.
Why this document did not explain the creation of process code on the outbound side. 38
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.
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_STUID 2. Idoc Type (Transaction: WE30) 3. Message Type (Transaction: WE81) and 4. 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 dont, anyway you will end up doing it as the idocs will not get posted in the receiving system.
Importing Parameters: Parameter Name INPUT_METHOD MASS_PROCESSING Exporting Parameters: Parameter Name WORKFLOW_RESULT APPLICATION_VARIABLE IN_UPDATE_TASK CALL_TRANSACTION_DONE Tables: Parameter Name IDOC_CONTRL IDOC_DATA IDOC_STATUS RETURN_VARIABLES SERIALIZATION_INFO Exceptions: Name WRONG_FUNCTION_CALLED Description Wrong FM has been called Type / Like LIKE LIKE LIKE LIKE LIKE Associated Type EDIDC EDIDD BDIDOCSTAT BDWFRETVAR BDI_SER Type / Like LIKE LIKE LIKE LIKE Associated Type BDWF_PARAM-RESULT BDWF_PARAM-APPL_VAR BDWFAP_PAR-UPDATETASK BDWFAP_PAR-CALLTRANS Type / Like LIKE LIKE Associated Type BDWFAP_PAR-INPUTMETHD BDWFAP_PAR-MASS_PROC
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.
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_INS Input Type: 0 Mass Processing Dialog Allowed: do not check the check box.
After entry: 41
Click on the change button and click on new entries. Screen when New Entries button is clicked: 42
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.
43
While saving it would ask for a workbench request. Save it in an appropriate workbench request.
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: 48
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.
Give the object type as IDOCAPPL. Do not maintain any start event.
button:
button 52
Now double-click on the logical message on the left side of the above pane. The following screen would appear 53
Click on New Entries: The following screen would be opened for input
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)
Select the partner EC6CLNT950 (This has been already created This is the sending system) Click on the Insert Button on the Inbound Parameters side.
Message Type: Created in WE82 Process Code: Created in WE42 And say Trigger Immediately
Hit Enter: 58
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: 59
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. 60
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. 61
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.
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).
63
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.
64
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.
65
66
67
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)
68
The entry with STUID = 204 (marked in RED) has been inserted.
Lets check WE02 (Give at least a part of the Basic Type with wild character)
69
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 its values) this has been filled by the program 2. Data Record Filled in our program. Carries the actual data and 3. 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.
70
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. Lets get back to the receiving P47 system:
71
Transaction: BD87: Transaction used for looking at Inbound Idocs. (At least specify part of message type)
72
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).
73
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!
74
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.
75
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). 76
77
Click on create
button. 78
Obj. Name: Z_PICTURE_RAISING_SUN Description: Raising Sun to be put on Initial Screen. Enter the data:
Click on Import
button.
79
Choose the path for the BMP file from the desktop/presentation server.
80
Update the DB Table: SSM_CUST with ID: START_IMAGE, with the image just uploaded.
81
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.
83
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.
84