Send | Explanation of sending transactions

For initial mass transfer of FSM-relevant objects, especially on production environment, it’s recommended to use the so-called full sync functionality. Learn more: https://proaxia-prod-doc.atlassian.net/wiki/spaces/PFCC/pages/1831108615.

Sending transactions can be found in the ‘Send’ folder of FSM Cloud Connector area menu and are used for transfer of objects from SAP ECC/S4 to SAP FSM.

(S4)PACG 200 SP09 You can navigate to most sending transactions also using the dedicated button in the corresponding customizing transaction, e.g.:

All sending transactions use a similar interface. Let’s use https://proaxia-prod-doc.atlassian.net/wiki/spaces/PFCC/pages/38175368 as an example.

This transaction serves the purpose of transferring service call types defined in https://proaxia-prod-doc.atlassian.net/wiki/spaces/PFCC/pages/2094727169 from SAP ECC/S4 to FSM. If not executed, SAP service call types won’t be visible in FSM.

To execute the sending transaction, click the ‘Execute’ button. If the transfer was successful, a pop-up window will be displayed. If there’s no pop-up window, no object was sent. This means that no object was relevant for transfer, e.g. because of incorrect object assignment (see //).

Objects are transferred to FSM using idocs, which are then converted into XML and delivered as such to FSM. Generated idocs can be displayed using transaction or WE02.

The following parameters are available in most sending transactions:

Save log	Store the log generated by the program
Display log	Display a pop-up window with the log generated by the program
Delete flag	Generate a deletion request (instead of regular transfer). The objects will be deleted permanently from FSM. Idoc properties - TRANSACTION TYPE D.
Force sending	By default, FSM Cloud Connector prevents re-transfer of a message which was already sent (transfer of an object which was already sent and hasn’t changed ever since). This is called the hash mechanism. Once a given object in SAP is changed, it can be sent to the Cloud and stored in hash DB. The Cloud contains normally the subset of the fields of the SAP objects. Sometimes there are changes in SAP, which are not relevant for the Cloud as they refer to non-relevant fields. Resending of the object in that case will not harm but produces unnecessary data transmission. The comparison if a relevant change happened based on stored hash in DB and the hash generated from actual field contents. Thereby for some objects (e.g. Material) a check is foreseen: if the change is not Cloud-relevant, then the object data does not have to be sent. To omit that check and re-transfer an unchanged object (e.g. for test purposes or to unblock it in FSM), keep the ‘Force sending’ flag active.
Soft delete flag	Generate a reversible deletion request (instead of regular transfer). The objects will be marked as deleted in FSM, but if resent without deletion flag, they will be restored with the same GUID. This approach is safer than the one above, especially for objects which have plenty of relationships, e.g. items. Idoc properties - TRANSACTION TYPE C, DELETED X.
Inactive flag	Transfer an object as inactive. Depending on an object, it can be displayed as inactive in FSM UI or hidden. Idoc properties - TRANSACTION TYPE C, INACTIVE X.

List of all sending transactions available in FSM Cloud Connector