Objects changed in FSM remain blocked until they are successfully processed by SAP ECC/S4. In case of an error occurring on the SAP side during the inbound processing, the object block is kept in FSM. It can be prevented with the ‘Error confirmation’ functionality sending a special message back to the cloud, which unblocks the object. Additionally, the error description from SAP ECC/S4 can be accessed in SAP FSM.
Prerequisites
The Message Broker must be of version 3.11 or higher for this functionality to work correctly.
/PACG/ECM_OBJERROR does not require any particular configuration. Errors occurring on the SAP ECC/S4 side for a given object will be transferred to FSM if this functionality is enabled for the relevant message type in transaction /PACG/ECM_CLSASSIGIN - FSM Connector's Incoming Messages Configuration, field ‘Error Conf’:
Further insight
/PACG/ECM_OBJERROR is analogical to the already existing /PACG/ECM_OBJCONF. These two in fact are not sent to FSM as XML messages, but instead they are processed by Message Broker which in turn calls dedicated methods of the Transporter. The schema below shows how the process works in SAP.
Error messages are communicated using idocs of type /PACG/ECM_ITYPE_OBJERROR:
MESTYPE | Type of the message which couldn’t be processed correctly, e.g. SERVICECALL. |
|---|---|
EXTGUID | GUID of the object which failed to be processed correctly. |
ERRORCODE | An error code consists of a message type, message ID and message number, e.g. E/PACG/ECM_MAIN 378. |
ERRORMESSAGE | Message description, e.g. Creation of service order for comp 0008: No default type could be found. |
MSGID | ID of the message which failed to be processed correctly. |
Idoc /PACG/ECM_ITYPE_OBJERROR remains in status 18.
After the OBJERROR is sent back to FSM, the object which initialized the process becomes unblocked, but there is no information displayed to the end user that processing in SAP backend failed which means that it is undistinguishable if the process was successful or not what in the end may lead to serious inconsistencies between FSM and SAP.
Example 1 - service call update fails because of service order being locked in SAP ECC/S4
The example below illustrates an error communicated to SAP FSM when the modified service call’s service order was being blocked by a user in SAP ECC/S4.
Ensure that ‘Error conf’ is enabled for the relevant message type in transaction /PACG/ECM_CLSASSIGIN - FSM Connector's Incoming Messages Configuration:
Block a service order in SAP ECC/S4 and modify the related service call in SAP FSM:
The service call idoc cannot be processed successfully.
An object error idoc is transferred to SAP FSM. It contains information about the order being locked.
The service call becomes unblocked in SAP FSM. The message is stored as an Event in the System Monitoring tab.
Example 2 - service call creation fails
The example below illustrates an error communicated to SAP FSM when a service order cannot be created for an FSM service call.
Ensure that ‘Error conf’ is enabled for the relevant message type in transaction /PACG/ECM_CLSASSIGIN - FSM Connector's Incoming Messages Configuration:
Creation is not allowed for any service order type in transaction /PACG/ECM_SCTD:
Create a service call in SAP FSM.
The service call idoc cannot be processed successfully.
An object error idoc is transferred to SAP FSM. It contains information about the last error log.
The service call still exists in SAP FSM. It becomes unblocked.
Notice that in this scenario, the ‘Error object’ functionality is risky to use. There is no information displayed to the end user that processing in SAP backend failed which means that it is indistinguishable if the process was successful or not, what in the end may lead to serious inconsistencies between FSM and SAP.
The error message can be found as an Event in the System Monitoring tab.
