Versions Compared

Old Version 9

changes.mady.by.user proaxia

Saved on

compared with

New Version 10

changes.mady.by.user proaxia

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info

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: Full sync.

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. All sending transactions use a similar interface. Let’s use /PACG/ECM_SCTMASTER - Service Call Type as an example.

This transaction serves the purpose of transferring service call types defined in /PACG/ECM_SCTD – Service Call types definition: Overview and Detail 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 /PACG/ECM_PLAS - Plant Assignment//PACG/ECM_SAASG - Sales Area Assignment//PACG/ECM_NOAS - No Object Assignment).

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 /PACG/ECM_COCKPIT - FSM Connector Cockpit 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.

Expand
titleLearn more about 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

Page Tree
rootSend | Explanation of sending transactions