Versions Compared

Old Version 11

changes.mady.by.user proaxia

Saved on

compared with

New Version 12

changes.mady.by.user proaxia

Saved on

Key

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

Message Broker is installed as a Windows service. There can be several instances of FSM Cloud Connector Message Broker installed on a single machine (PROD, TEST, DEV). When configured correctly, these services should be set-up to start automatically at system startup. Sometimes there may be a need to start, stop or restart the service. The service instances can be found in Windows services window with the following names:

  • E4C PROD Message Broker Component

  • E4C TEST Message Broker Component

  • E4C DEV Message Broker Component

Anchor
_Toc286915288
_Toc286915288
Troubleshooting

Anchor
_Toc33532473
_Toc33532473
Object not created on Cloud

Symptoms: object is created/updated in SAP, but the changes are not transported to the Cloud. The following steps are to be taken:


Check if an IDOC for given object exists


Check if an outbound IDOC for the given object has been created as described in section IDOC monitoring. If the IDOC doesn't exist, it should be verified, that the business rules (e.g. status rules, company code/sales area filtering, etc.) defined in the system include the given object for being synchronized with the cloud. If, according to the rules mentioned above, the document should be synchronized with the cloud, but the IDOC has not be generated, application logs should be checked as described in section Application logs. If the application logs do not provide any hint why the IDOC is missing, please contact your FSM Cloud Connector implementation partner for assistance.


If IDOC exists, check its status code


If the outgoing IDOC has been created, its status code can be used to determine, what problems may have occurred, as described in the table below.

Status

Description

03

Status 03 indicates, that the IDOCs have not been sent to the Message Broker component. This may happen because of the following reasons:

  • outbound options not been configured as Transfer IDOC immediately in Partner Profile (transaction WE20) for logical system /PACG/ECM and the given IDOC type

  • qRFC Outbound Queue has stuck – the queue status can be checked and message processing can be brought back to the normal state in transaction SMQ1, as described in section Message queues.

  • message broker is down – you may want to verify, if the respective Windows service is up and running as described in section Deleting Master Data in the Cloud

    INTRODUCTION

    When the master data are sent from SAP to the Cloud (e.g. Activity Codes based on SAP Inspection Catalog Codes), the IDocs are generated – every IDoc corresponds to one master data object. The IDoc contains the main segment (different one, depending on the object type). The segment contains a field playing the role of an identifier of the object. E.g. in case of Activity Code based on SAP Inspection Catalog Codes the IDoc with IDoc Type /PACG/ECM_ITYPE_SRERRCOD is issued for every Activity Code. The IDoc contains a segment /PACG/ECM_IS_SRERRCOD, the field ID identifies uniquely the object in the Cloud:


    Every FSM Cloud Connector IDoc contains a segment /PACG/ECM_IS_CONTROL, playing a role of a control segment. The field TRANSACTION_TYPE informs the Cloud whether the object is to be created in the Cloud (or updated, if it exists) or deleted:

  • 'C' – corresponds to the creation/update request,

  • 'D' – corresponds to the deletion request.


    If you want to delete the given object in the Cloud, you must create an IDoc with TRANSACTION_TYPE = 'D'.

    SENDING DELETION REQUESTS USING THE PROGRAMS SENDING THE OBJECTS

    Many programs sending master data from SAP to the cloud contain a checkbox "Delete flag", e.g.:


    In that case the selected objects will be sent with TRANSACTION_TYPE = 'D' – they will be actually deleted in the Cloud. This approach can be useful if we have the master data object in SAP and we want to send it together with the information that it is to be deleted.

    USING TRANSACTION /PACG/ECM_SEND_DELRQ

    It can be the case however, that the object does not exist in the SAP any longer and we want to delete it in the Cloud as well. In that case resending this object with deletion flag is problematic. In that case the transaction /PACG/ECM_SEND_DELRQ can be used. Two ways of usage of this transaction are possible:

  1. We know the identifiers of the objects; we want to delete the object in the Cloud for the given identifiers.

  2. We do not know the identifiers of the objects, we rather would like to say "delete the objects which were created from SAP by the IDocs type X, created within last Y months".


    In that case the IDoc with IDoc Type /PACG/ECM_ITYPE_OPERATION, Message Type /PACG/ECM_OBJDELREQ is used. The IDoc is generic, its data contains the object type used in the Cloud (e.g. ACTIVITYCODE) and the identifier sent by SAP (e.g. G5ZKAMCAU2).


    Tip: Open the XSLT Transformation and locate the node "idElement" to find out, what Cloud Message Type should be used:

    Deleting the objects for the given identifiers

    You know, that you want to delete the Activity Codes with the identifiers X1 and X2. Execute the Transaction /PACG/ECM_SEND_DELRQ with the following Selection Screen:


    You provide the identifiers in the field "Object key":


    The following protocol is generated:


    Deleting the objects based on the IDocs sent

    You don't know the identifiers of the objects which are to be deleted. Instead the objects which have been created by the outgoing IDocs should be retrieved from the database, their identifiers should be collected and then the deletion request should be sent. You execute the program providing the selection criteria for the IDocs search:


    Enter the following fields:

  • Basic type: the IDoc type of the IDoc:

  • Segment type: The Segment name, in which the Identifier is passed:

  • Field name: field holding the identifier of the object:

  • Created on: date range, when the IDocs were created.

    It is good practice to execute the program with the parameter 'Write Identifiers on Screen" = X and "Test Mode" = X. In that case the outgoing IDocs will not be created and the identifiers determined by IDoc search will be written on the screen:


    Once you have verified the identifiers, you can uncheck the "Test Mode" – the IDoc with deletion request will be sent to the Cloud:

  • Message Broker administration

  • check if the web service of Message Broker is available from SAP. In order to do that, an FSM Cloud Connector menu should be opened (transaction code /n/pacg/ec while in SAP main menu) and Administration/Ping Message Broker option should be selected. Upon execution the program will either respond with a success message (connection works), network error message (network problem, service not available or listening on a different port than configured for the client proxy in SOAMANAGER transaction) or SOAP failure, which stands for a problem with web service/SOAP format

  • check in Message Broker log file if it doesn't contain any error entries related with the messages received from SAP

18

Status 18 indicates, that the message has been sent to (and received by) Message Broker, but its reception has not been confirmed by the cloud. This may happen because of the following reasons:

  • connection between Message Broker and Cloud has been broken, which could be an effect of network failure or of the Cloud being down

  • problems in the Message Broker – please check Message Broker log and verify if there are no error entries related to the message processing

  • message confirmation failed to be delivered – you may want to restart the Message Broker windows service and verify if this helps

Note: the Cloud always confirms the message reception, even if it fails to parse message, or so. Thus status 18 indicates communication problems, not the problems with the message contents.

41

Status 41 means, the message has been received by the cloud. If the data do not seem updated in the cloud, this could mean one of the following:

  • the message was not correct and its parsing failed on the cloud, you may want to set Message Broker logs to DEBUG level, send the message again (e.g. by updating and saving the business object in SAP again) and check if the message contents are correct

  • the message refers other objects, that are not present on the cloud (e.g. a service call refers an equipment, that has not been synchronized or has been deleted from the cloud), you may update references and send the message again (e.g. by updating and saving the business object in SAP again)

  • there is a problem in the Cloud not related to the particular message, the case should be investigated by SAP

Anchor
_Toc286915290
_Toc286915290
Object not created in SAP

Symptoms: object is created/updated in Cloud, but the changes are not transported to SAP. The following steps are to be taken:


Check if an IDOC for given object exists


Check if an inbound IDOC for the given object has been created as described in section IDOC monitoring. If the IDOC doesn't exist, there can be two possible reasons:

  • the message has not been delivered to SAP by Message Broker – check if the message broker windows service is up and running as described in section

Anchor
_Toc33532475
_Toc33532475
FSM Cloud Connector Monitoring Cockpit

Customizing

Use FSM Cloud Connector Menu (Transaction /PACG/EC), choose "Customizing" node and execute the "Cockpit Configuration" transaction to configure FSM Cloud Connector Monitoring Cockpit:



There is one record necessary:



Please enter:

  • FSM Cloud Connector technical username

  • SAP Workflow user

  • Job name for processing unprocessed incoming IDOCs (SAP Standard program RBDMANI2).


Anchor
_Toc33532477
_Toc33532477
Using of FSM Cloud Connector Monitoring Cockpit

Use FSM Cloud Connector (E4C) Menu, choose "Administration" node and choose "IDOC Cockpit" transaction to start FSM Cloud Connector Monitoring Cockpit:

Image RemovedImage Added


Alternatively use the transaction code /PACG/ECM_COCKPIT (remember to prefix the transaction name with "/n" when executing the transaction manually). FSM Cloud Connector Monitoring Cockpit starts with following screen:




There is a navigation panel for choosing the given company or all companies in the top left area:


After choosing a company, the Monitoring Cockpit shows data for the given company in the upper part:


In the IDOC Part click one of 24 buttons to analyze IDOCs for example:


There are for possibilities in IDOC Report:

  • Set IDOC as processed (set IDOC status)

  • Process IDOC – call transaction BD87

  • Display processing log as in transactions WE02/WE05

  • Display IDOC content as in transactions WE02/WE05


The top right panel presents the information about the status of incoming and outgoing FSM Cloud Connector queues. It is possible to call transactions SMQ1 and SMQ2:


The middle panel presents the information about FSM Cloud Connector entries in COGI Transaction. It is possible to call transaction COGI:


The bottom panel consists of 5 parts:

  1. An Information about a Job for processing of unprocessed IDOCS und a possibility to call transaction SM37 (Job overview):

  2. Runtime errors overview and a possibility to call transaction ST22:

  3. Show FSM Cloud Connector Logs – transaction SLG1 is launched (for the given user or all users):

  4. Status of Message Broker and a possibility to call a transaction performing connection test to the Message Broker:

  5. Status of SAP Workflow Configuration:

Image RemovedImage Added

FSM technical user authorization in ERP

There are 2 different approaches to provide access to the ERP technical user for FSM as per business needs.


Anchor
_Toc33532479
_Toc33532479
Provide SAP_ALL access

No other authorization necessary if SAP_ALL is provided. Also, as the user is used only for FSM process, providing SAP_ALL is ideal considering it is a background process, and no one manually uses it.


Anchor
_Toc33532480
_Toc33532480
Business authorization and Web service access

If the customer decides not to provide SAP_ALL, then the user must be given below accesses.

  • Business authorization for this user varies based on customer needs and their ERP process for SAP CS module. Basically, the customer must conclude, which business processes/transactions the technical user must be authorized.

  • The authorization for E4C specific webservices should be provided, the highlighted objects in E4C webservice must be given authorization.


Authorization object for webservice: S_SERVICE

Hashkey (SRV_NAME)

Type (SRV_TYPE)

External Service name

569DB6EFB96E9BFA0E70FFC925A098

HS

/PACG/ECM_WS//PACG/ECM_S_WSIDOCCONF

6E4B06B8096C3C00FF7B88EF7237CB

HS

/PACG/ECM_WS//PACG/ECM_S_WSIDOCRESEND

C323DDB6C106A74EFAE6B9CB8E556A

HS

/PACG/ECM_WS//PACG/ECM_S_WSIDOCFULLSYNC

E427AB8C3CBEF676501E504BBEE75F

HS

/PACG/ECM_WS//PACG/ECM_S_WSINPUT