General process overview
The diagram below demonstrates generalized outbound idoc processing (SAP ECC/S4 → SAP FSM).
Detailed process example
Detailed description of the outbound idoc processing. In this scenario an activity is transferred to SAP FSM with the sending program /PACG/ECM_TRIG_ACTIE - E4C Activity.
Keep in mind that even though most of the steps described below are relevant for the majority of objects, some of them are ACTIVITY-specific.
Run the sending program for the object
Navigate to the sending program for activities - /PACG/ECM_TRIG_ACTIE. Enter an activity number and a relevant company ID. Click execute.
Start of selection in the sending program
Object key table
In the activity transfer program the values entered in the select-option ‘Activity number’ (S_ACTNR) are looped at and appended to the object key table (LT_OBJKEY). This table will later be passed to the selection class.
Class assignment
Based on the message type, a relevant class assignment is retrieved from table /PACG/ECM_CLASGN. In this case the message type is ‘/PACG/ECM_ACTIVITYOUT’.
Class assignment for each message type is maintained in transaction /PACG/ECM_CLSASSIG - FSM Connector's Outgoing Messages Configuration. Notice that for message type ‘/PACG/ECM_ACTIVITYOUT’ the following selection class ('Data selection') and outbound idoc class ('IDOC class') are currently defined.
If no selection class was found for this message type, the program wouldn’t proceed. The selection class is used for dynamic object creation.
Notice that in the selection class’s class-constructor sales area assignment is read.
Proceed to the selection class
Once the LO_DATASEL object has been created, the interface method ‘SEND' can be called.
Notice which parameters are passed to this method and that the activity number entered on the selection screen is passed in internal table LT_OBJKEY as parameter IT_OBKEY. Further processing will take place in the method /PACG/ECM_IF_S_DATA_SEND~SEND of selection class /PACG/ECM_CL_S_SEL_ACTIVITY_E.
Selection class
The general purpose of this method is to prepare a relevant list of objects to pass for the idoc outbound class.
Example of selection logic #1 - sales area assignment check
Check if any sales area is maintained for the target company and object ‘ACTIVITY’ in Sales Area assignment. If not, the object is not relevant for transfer.
If sales areas are found, it is checked if the selected activity’s sales area matches the retrieved values.
Example of selection logic #2 - activity mapping check
Another validation check in the selection class method before proceeding to document generation is ensuring that the activity’s type (in this case it’s ‘ASSI’) can be found in the activity type mapping - transaction /PACG/ECM_ACTMAE - Activity code mapping.
Since such an entry can be found for company 1 and type ‘ASSI’, the execution proceeds.
Generate a document
An idoc document is created by method ‘CREATE’ of class /PACG/ECM_CL_S_IDOC. Notice which values are passed as parameters.
Take a look at the current ABAP stack.
Basic idoc control data is filled.
Based on class assignment of message type ‘/PACG/ECM_ACTIVITYOUT’ (to be precise, the 'Process code' field), a relevant function module name is determined.
The retrieved function module’s name is /PACG/ECM_S_IDOC_OUTPUT. It is now called to fill the idoc’s header and segments. Notice which data is passed as parameters.
Fill the idoc
Take a look at the current ABAP stack:
The outbound idoc class entered in the outgoing class assignment customizing will be used to retrieve specific data for each idoc field. In this case it is class /PACG/ECM_CL_S_IDOC_O_ACTI_E. It implements interface method ‘IDOC_OUTPUT’.
Idoc output class
Take a look at the current ABAP stack:
The idoc output class gathers all the additional data for objects retrieved in the selection class so that all relevant idoc fields can be filled with properties.
Back to the document generation
The final result of output idoc class processing is the idoc data table which will be passed back to function /PACG/ECM_S_IDOC_OUTPUT.
Hash handling
If no exception was raised and the class assignment configuration has the ‘Use hash’ checkbox set, a hash will be created for the transferred activity.
Hash handling prevents resending of already transferred idocs. A hash is created for this activity based on the idoc’s content.
If the same hash has been generated before for this company, message type and activity number (can be found in table /PACG/ECM_AHASH), the ‘forcesend’ parameter must be checked. In such a case the old hash will be overwritten. Otherwise, the activity won’t be transferred at all.
The idoc will be distributed using the SAP standard function ‘MASTER_IDOC_DISTRIBUTE'.
Back to the selection class
The idoc’s document number is passed back to the selection class method.
Process the idoc
A function module responsible for idoc processing is assigned to ports in transaction WE21.
Idoc segments are read with the function 'EDI_DOCUMENT_OPEN_FOR_PROCESS' based on the imported document number.
The function exports the control segment. If no processing errors were raised (e.g. related to idoc’s status) , the function 'EDI_SEGMENTS_GET_ALL' retrieves all the idoc segments.
Send data to the communication channel
Data is sent to the channel with method ‘PROCESS’ of an instance of class /PACG/ECM_CL_S_COM_FACADE.
After determination of the communication channel, the data will be passed for sending to the communication channel.
XML transformation
Take a look at the current ABAP stack:
It is in method /PACG/ECM_IF_S_CHANNEL~SEND of class /PACG/ECM_CL_S_CHANNEL_XML_WS where the XML transformation will be called.
The transformation logic is the same for all message types apart from /PACG/ECM_ATTCHMOUT, /PACG/ECM_CHECKLIST_D_O and /PACG/ECM_GENERIC (which require special handling). The outgoing class assignment configuration is read once again, this time to retrieve the XSLT transformation program name. In this case it is /PACG/ECM_OUT_ACTIVITY_1.XSLT. The retrieved XSLT transformation is called.
The source XML will be transformed to FSM-friendly format (tag names will correspond to SAP FSM property names). Currently, the XML reflects the idoc field names, as shown below:
The control segment and the first segment:
<?xml version="1.0"?> -<_PACG-ECM_ITYPE_ACTIVITY_OUT> -<IDOC BEGIN="1"> -<EDI_DC40 SEGMENT="1"> -<TABNAM> -<![CDATA[EDI_DC40]]> </TABNAM> <MANDT>300</MANDT> <DOCNUM>0000000008375420</DOCNUM> <DOCREL>701</DOCREL> <STATUS>03</STATUS> <DIRECT>1</DIRECT> <OUTMOD>2</OUTMOD> -<IDOCTYP> -<![CDATA[/PACG/ECM_ITYPE_ACTIVITY_OUT]]> </IDOCTYP> -<MESTYP> -<![CDATA[/PACG/ECM_ACTIVITYOUT]]> </MESTYP> <SNDPOR>SAPERD</SNDPOR> <SNDPRT>LS</SNDPRT> <SNDPRN>ERDCLNT300</SNDPRN> <RCVPOR>/PACG/ECM1</RCVPOR> <RCVPRT>LS</RCVPRT> <RCVPRN>/PACG/ECM1</RCVPRN> <RCVSAD>0001</RCVSAD> <CREDAT>20210216</CREDAT> <CRETIM>230215</CRETIM> <SERIAL>20210216230209</SERIAL> </EDI_DC40> -<_PACG-ECM_IS_CONTROL SEGMENT="1"> <MESSAGEID>30000000000012937381</MESSAGEID> <ZONLO>CET</ZONLO> <TZONE>3600</TZONE> <TRANSACTION_TYPE>C</TRANSACTION_TYPE> <COMPID>0001</COMPID> <CLOUDACCOUNT>proaxia</CLOUDACCOUNT> -<CLOUDID> -<![CDATA[proaxia_development]]> </CLOUDID> <EXTMSGTYPE>ACTIVITY</EXTMSGTYPE> <ID>0100009272</ID> -<_PACG-ECM_IS_ACTIVITY SEGMENT="1"> <TSTAMP>2020-11-23T12:52:39Z</TSTAMP> <OTYPE>SERVICECALL</OTYPE> <OID>000004005665</OID> <ATYPE>ASSIGNMENT</ATYPE> <BP>0000700521</BP> <RESPONSIBLES>X/00900121</RESPONSIBLES> <STATUS>OPEN</STATUS> <SUBJECT>000004005665-hiudadsdfwdnsafsdfda</SUBJECT> <START>2020-11-23T12:52:00Z</START> <END>2020-11-23T13:52:00Z</END> <SAPKEY>0100009272</SAPKEY> <ADDRESS>SRVC/000004005665</ADDRESS> <CHECKEDOUT>false</CHECKEDOUT> <EARLIESTSTART>2020-11-23T12:52:00Z</EARLIESTSTART> <DUE>2020-11-23T13:52:00Z</DUE> <DURATION>60</DURATION>
After successful transformation, the XML’s tags correspond to SAP FSM property names:
The control segment and the first segment:
<?xml version="1.0" encoding="UTF-8"?> -<ACTIVITY> <id objectType="ACTIVITY" keyValue1="0100009272"/> <inactive>false</inactive> <deleted>false</deleted> <object objectType="SERVICECALL" keyValue1="000004005665"/> <businessPartner objectType="BUSINESSPARTNER" keyValue1="0000700521"/> <address objectType="ADDRESS" keyValue1="SRVC/000004005665"/> <type>ASSIGNMENT</type> <status>OPEN</status> <code>0100009272</code> <subject>000004005665-hiudadsdfwdnsafsdfda</subject> <checkedOut>false</checkedOut> <remarks/> <predecessorActivities/> -<responsibles> <PERSON objectType="PERSON" keyValue1="X/00900121"/> </responsibles> <startDateTime>2020-11-23T12:52:00Z</startDateTime> <endDateTime>2020-11-23T13:52:00Z</endDateTime> <dueDateTime>2020-11-23T13:52:00Z</dueDateTime> <earliestStartDateTime>2020-11-23T12:52:00Z</earliestStartDateTime> <durationInMinutes>60</durationInMinutes>
The XML is then converted into UTF-8 string and certain ASCII codes are removed from it.
Proxy - send the data to the Message Broker
Before sending the data to the Message Broker, the logical port is determined from mapping in table /PACG/ECM_CACC (to be customized with transaction /PACG/ECM_CACC - Company account assignment).
The method ‘SEND_XML_MESSAGES’ of class /PACG/ECM_CL_S_WS_PROXY will be used to pass the XML to a webservice.
Notice that sending of XML will be repeated up to 30 times (the loop will be escaped once the sending is successful). Sending failures might be caused by Message Broker disfunction or internal network issues.
Idoc status and log update
Idoc statuses will be updated based on the success of transfer.
Document process closing is conducted by function ‘EDI_DOCUMENT_CLOSE_PROCESS’. Finally, the statuses and logs are saved by a commit.
Back to the sending program
The successful transfer is confirmed by logs. A new idoc of type /PACG/ECM_ITYPE_ACTIVITY_OUT can be found in transaction WE02.
