0% found this document useful (0 votes)
229 views48 pages

E4C Administration and Monitoring Guide

The document provides guidance on monitoring and administering E4C, including: - How to monitor IDOCs using SAP transactions WE02 and WE10 and understand their various statuses as they are processed - Key statuses for outgoing IDOCs include 18 (sent to message broker) and 41 (confirmed by cloud) and for incoming IDOCs include 53 (properly processed) and 51 (not properly processed) - How to view application logs to understand what objects were created in SAP from incoming IDOCs

Uploaded by

Alexis Benarroch
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
229 views48 pages

E4C Administration and Monitoring Guide

The document provides guidance on monitoring and administering E4C, including: - How to monitor IDOCs using SAP transactions WE02 and WE10 and understand their various statuses as they are processed - Key statuses for outgoing IDOCs include 18 (sent to message broker) and 41 (confirmed by cloud) and for incoming IDOCs include 53 (properly processed) and 51 (not properly processed) - How to view application logs to understand what objects were created in SAP from incoming IDOCs

Uploaded by

Alexis Benarroch
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 48

E4C Administration and Monitoring Guide

Version from: 2017-11-07

Your Contact
Telefon: +41 56 4182080
Email: [email protected]
Web : http://www.proaxia-consulting.com

proaxia consulting group ag


Industriestrasse 176 | CH-8957 Spreitenbach
Tel. +41 (0)56 418 2080 | Fax +41 (0) 56 418 2081
www.proaxia-consulting.com
Content
1 Introduction ..................................................................................................................... 3
2 E4C Monitoring................................................................................................................. 3
3 E4C Administration ..........................................................................................................18
4 Troubleshooting ..............................................................................................................36
5 E4C Monitoring Cockpit ...................................................................................................49
6 SAP Client Copies .............................................................................................................55

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 2 von 48


1 Introduction
The goal of this document is to provide the information about the Administration and Monitoring of E4C. Both
SAP side (Data Extractor) and Message Broker are mentioned.

2 E4C Monitoring

2.1 SAP Processing


2.1.1 IDOC Monitoring

The IDOCs (both sent from the SAP to the Cloud and from the Cloud to the SAP) can be monitored with the
standard SAP transactions.
The mostly used transaction is WE02:

Notice, that all IDOCs types which are relevant for E4C start with /PACG*.
Once you want to search for the IDOCs in the given Date/Time range this transaction is very useful.

Double click the IDOC Number. The content of the IDOC is presented.
By expanding the node “Data records” you can analyze the content of the IDOC:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 3 von 48


By expanding the node “Status records” you can analyze the Status of the IDOC:

The transaction WE10 can be used if we want find the IDOCs for the given type and object.
Example:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 4 von 48


We want to find all IDOCs related to the outgoing equipment for the Equipment number
000000000010000765 (to check whether this equipment has been sent to the Cloud). The selection screen
can in that case look like this:

The unprocessed IDOCs should be monitored by the Administrator.


Execute the WE02 transaction with the following parameters:

(Basic Type = /PACG/ECM*, IDOC Status not equal to 41 and 53).

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 5 von 48


Once there are some IDOCs found, and they stay with this status permanently, you should investigate them
further.
The exception is: the IDOCs with the Message Type = /PACG/ECM_RESENDEND and /PACG/ECM_CONFIRM
should have the Status 18 and this is ok by design.

2.1.1.1 Outgoing IDOCs

The outgoing IDOCs are created when:


- the certain events in SAP occur (e.g. the Equipment has been created/changed, the Customer master
data has been created/changed, the Activity has been created/changed etc.),
- the certain object have been sent explicitly to the Cloud by the Administrator (e.g. the transaction
/PACG/ECM_USERMASTER has been used to send the Users master data to the Cloud).

Once the IDOC has been successfully sent to the Cloud, it should have the status 41:

The following Statuses are set during the IDOC lifetime:


Statu Description
s

01 The IDOC has been created (normally this status is set for a very short time, very soon the next
status should be set)

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 6 von 48


30 The IDOC is ready for dispatching (normally this status is set for a very short time, very soon the
next status should be set).

03 The IDOC has been passed to the port. The port in case of E4C is the Web Service call to the
Message Broker. All the IDOCs are configured in the way that they are to be sent immediately.
However the IDOCs are sent to the cloud via the queue (the transaction SMQ1). The queue name
for the outgoing IDOCs is /PACG/ECM_STD_OUT. If there are the IDOCs with this status (usually
during full synchronization) they are usually waiting in the queue for being sent. So during the full
synchronization (which can take even hours) we can observe the IDOCs with this status

As long as the outgoing queue is not blocked and the amount of records in the Queue is changing
(increasing in the beginning of the synchronization and decreasing in later stage, when no new
IDOCs are create and the existing are sent) it means no malfunction.

29 Error in ALE Service. It means that the IDOC has not been sent. Usually it means that the
connection between SAP and the Message Broker is broken.

18 The IDOC has been sent to the Message Broker (the connection between the SAP and the Message
Broker is established, the Web Service call was successful). The process of sending the data from

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 7 von 48


the SAP perspective is almost finished (the data has been successfully sent using the Web Service).
However out of that Status we cannot claim, whether it is already in the Cloud or not. If the IDOCs
have the Status 18 for a very long time it most probably means, that the connection between the
Message Broker and the Cloud is broken. In that case you have to monitor the Message Broker.

41 The confirmation from the Cloud has been sent by the Cloud to the Message Broker, the Message
Broker has sent this information to the SAP, the Web Service at SAP side has been successfully
called, and the function at SAP side has successfully updated the IDOC in question. The process of
sending the IDOC has been completed.

Warning: the IDOCs with the Message Type = /PACG/ECM_RESENDEND and /PACG/ECM_CONFIRM
are exception here – they are never confirmed, they never get the status 41 – they will always stay
with the Status 18 (it is by design).

2.1.1.2 Incoming IDOCs

The incoming IDOCs are created when the objects are to be created/updated at SAP side (triggered by the
Cloud).
Once the incoming IDOC has been successfully processed, it should have the Status 51:

The following Statuses are set during the lifetime of the IDOC:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 8 von 48


Status Description

60 IDOC has been created (normally this status is set for a very short time, very soon the next
status should be set)

64 IDOC ready to be transferred to the application (normally this status is set for a very short
time, very soon the next status should be set)

62 IDOC passed to the application (normally this status is set for a very short time, very soon the
next status should be set)

53 The IDOC has been properly processed.

To see more details you should double click at the status 53:

The following screen should appear. Choose “Application Log”:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 9 von 48


The log is presented:

You will find this log also if you call the transaction SLG1 directly, but if you follow this
procedure you are directed immediately to the right log.

By analyzing this log you can find out, which document has been created at SAP side (e.g. the
Activity Number for the incoming Activities).

Be aware, that all objects in SAP are created/updated by the same communication user
(configured in the Message Broker) – you are not able to distinguish which person has created
the object (in contradiction to the documents created by the users using SAP GUI).

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 10 von 48


51 The IDOC has not been properly processed. To see more details you should double click the
status 51:

The following screen should appear. Choose “Application Log”:

The log is presented:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 11 von 48


By analyzing the log you can decide what was the reason of the failure and eventually
reprocess the IDOC with the standard transaction BD87.

2.1.1.3 Message Queues

The transaction to monitor the Queue is SMQ1.


The outgoing IDOCs are sent to the Cloud through the Queue. The incoming IDOCs are processed using the
Queue as well. By using the queue we make sure, that the Documents are delivered and processed in the
right order. However the consequence of the queue is, that if the processing of the given document was not
successful (e.g. because of the short dump, the connection failure between SAP and the Message Broker) the
queue is stopped. As far as the incoming IDOCs are concerned an attempt to process the IDOC is performed
and if the certain object could not be created in SAP (e.g. because of incorrect data) the IDOC gets the status
51 (the IDOC becomes red) and the processing is continued. In other words only the critical errors (like short
dumps or network errors) stop the Queue.
The following Queue identifiers are used:
Queue name Description

/PACG/ECM_STD_OUT Outgoing IDOCs

/PACG/ECM_STD_IN Incoming IDOCs

/PACG/ECM_FULLSYNC Full Synchronization Requests sent from the


Message Broker to the SAP

Normally the Queue should be empty.

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 12 von 48


If it is not empty but the processing takes place it points no malfunction as well (especially the full
synchronization is very time consuming operation – you can monitor the progress of handling the full
synchronization by analyzing the content of the Queue):

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 13 von 48


Once the queue is blocked, its status will be red:

This status (RETRY) will be set if the connection between SAP and the Message Broker is lost.

In that case the Queue is blocked. You could use the button (after double clicking the Queue) to push it.

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 14 von 48


However normally it should not be needed, if you configure the scheduler for RFC Destination = none during
the installation. Choose the following menu in SMQ1:

You will be presented with the Status of the Scheduler (consider RFC Destination = None):

If the Queue is blocked with the error RETRY, the queue will be pushed automatically by the Scheduler. Once
the connection between SAP and Message Broker is reestablished, the messages will be
sent to the Message Broker and finally to the Cloud.

It can be also the case, that the Queue is blocked with the message SYSFAIL. This can occur if there is e.g. a
short dump. In that case the SAP Scheduler will not push the Queue (it indicates the serious problem which is
not a candidate for the resending). In that case the Queue has to be pushed manually (after solving the
problem).
The Message Queue should be monitored by the Administrator.

2.1.2 Applicaton Logs

The logs of the application can be viewed with the following call of SLG1 transaction:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 15 von 48


You can either leave the Subobject Field with the default value * or make more specific selection (for the
certain type of the log):

Once you execute the transaction the logs for the given period of time will be presented:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 16 von 48


2.2 Message Broker
Besides message monitoring in SAP as described in Error! Reference source not found. paragraph above, it is
also possible to track the communication on the Message Broker level.
Message Broker produces log files that contain runtime information related to the message processing.
The messages are generated with the following log levels:
• DEBUG – the most verbose level, containing detailed information of message processing, including
content and metadata of XML messages being sent between SAP and Cloud
• INFO – contains entries for messages transferred, so that it is possible to track message exchange, but
no detailed information (i.e. no message content)
• WARN – entries generated for non-critical problems
• ERROR – entries generated for problems that prevent message exchange (problem to connect to SAP
or Cloud, application misconfiguration, etc.)

It is recommended, that the logging is configured at least at a WARN level, so that all unusual situations are
visible in the logs.
In a starting phase of using E4C it may be desirable to set logging level to DEBUG, even if causes big files to be
generated and brings some performance overhead.

The logging parameters (e.g. path to the log files, logging level, etc.) can be set in Message Broker
configuration file (see E4C Installation and Configuration Guide for details).
By default logging is set to a DEBUG level and files are generated in c:\tmp\e4c.log\ directory.

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 17 von 48


3 E4C Administration

3.1 User Administration


User accounts are synchronized between SAP and Cloud. As such, in order to enable a mobile user, the user’s
account has to be prepared in SAP first, then synchronized to the Cloud, where a license can be assigned to
the user. These steps are described in more details below.
It is important to note, that during user synchronization the user’s SAP password is not transferred to the
cloud.

3.1.1 SAP User preparation

You can either add personal no. or SAP username as relevant user to transaction /PACG/ECM_USER - E4C
users - Maintenance View. Please ensure NOT to maintain both for one person.
In case SAP users are maintained, please maintain infotype 0105 / subtype 0001 in corresponding HR mini
master of the person.

Attributes
- Subcontractor is to evaluate the type of user (information purpose)
- Plannable needs to be set when user should appear in planning board
- Not active flag is for inactivating user

3.1.2 Maintain SAP reference personal no. to user

It is necessary to maintain a reference between SAP user and employee personal number for the following
reason: when a service order is created in SAP, it is possible to assign technicians to it. The technician gets
assigned as a personal number. On the other hand, when the user logs in to the mobile application, he uses a
user name instead of the personal number.
In order to make the service call available to the given user in My Service Calls screen, we have to assign the
service call to a user name, not to the personal number.
In order to achieve the above, the E4C Data Extractor, while generating a message for a service order (service
call in the Cloud) tries to determine a user names for the personal numbers entered in the service order as

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 18 von 48


technicians. If the user can be determined, user name is used instead of the personal number and – in effect –
the service call becomes assigned to the given user in the mobile application.

The reference between the employee personal number and the SAP user name is maintained as described
below:
1. Launch the transaction PA30, enter the Personal number, press Enter:

2. In the Infotype field enter 0105, in the Subtype field enter 0001, choose button:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 19 von 48


3. In the field ID/number enter the SAP user name:

4. Save the changes.

3.1.3 Sending User Data

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 20 von 48


After having added user account for Cloud synchronization the user data has to be sent to the cloud.
In order to do that, the E4C menu should be opened (transaction code /n/pacg/ec while in SAP main menu).
In folders Send->Person transactions for User and Employee must be executed.

On a selection screen it is possible to select a user (or several users), whose data are to be transferred to the
Cloud. Upon execution respective IDOCs and Cloud messages are sent and in effect respective users /
employees are created / inactivated in the Cloud.

3.1.4 Cloud User Administration

In order to be able to login to the coresuite mobile application, the users account have to be synchronized
from SAP system to Cloud, as described above and licenses have to be assigned to them.

The user/license management is performed with a web browser in the coresuite store, at
https://store.coresuite.com/en/Account/LogOn . The user administrator should login with a cloud account
and password, that were used during the account registration (see E4C Administration and Monitoring Guide).

3.2 IDOC handling


3.2.1 Reprocessing the unprocessed incoming IDOCs

In general there can be 2 reasons that the certain incoming IDOCs are not processed (having the status 51):
- Temporary inability to process the IDOC (e.g. the attempt to register the Time Effort while the Service
Order is locked by another user),
- Other type of problem (e.g. invalid master data, invalid configuration, etc).
To minimize the effort of monitoring the unprocessed IDOCs and minimize the impact of the temporary
inability to process the IDOCs it is possible to schedule the periodic job, which makes the attempts to
reprocess the IDOCs with the status 51. However we should notice that:
- This approach makes sense only for the IDOCs having the status 51 because of temporary inability to
be processed,
- For performance reasons the set of the IDOCs included in that process should be limited by date (e.g.
current date or the IDOCs not older than 1 day).

Thereby launching this job does not mean, that the monitoring of the IDOCs is not needed – still it is.

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 21 von 48


The unprocessed incoming IDOCs (having the Status 51) can be reprocessed manually using the standard
transaction BD87.

There is also a standard program RBDMANI2 performing the reprocessing. This program can be scheduled as
the background job. The selection screen variant should be setup for that program. It can look like this:

Notice:
- Turn “Output List” off
- Include only the IDOCs with the Message Type = /PACG/ECM*
- Consider the IDOCs not older that the given amount of days.
As the job is to be run periodically, the “Created on” has to be determined dynamically”. When saving the
selection screen variant use the following:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 22 von 48


(it is crucial to use Greater or Equal operator)

(then chose the expected age of the IDOC to be considered, e.g. created yesterday or later)

It is crucial that after choosing the selection screen variant we see Greater or Equal operator and really
dynamic date calculation takes place (not the fixed one):

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 23 von 48


When setting up the job take care that you do it with the right SAP user (the same as configured in the
Message Broker).

3.2.2 Deleting unneeded Logs

Once the E4C IDOCs have been successfully processed or sent, the corresponding SLG1 Logs are not needed in
the system any longer. It is up to the Administrator whether they will stay on the system or will be deleted
with other Logs or will be deleted separately.
The transaction SLG2 can be used to delete the old Logs.
BE EXTREMELLY CAREFUL, NOT TO DELETE OTHER (NON E4C) LOGS AND NOT TO DELETE THE LOGS WHICH
ARE RELATIVELLY NEW (WHICH COULD BE HEPFUL FOR PROBLEMS DIAGNOSIS). BE EXTREMELLY CAREFUL TO
PROVIDE THE CORRECT “OBJECT” AND “TO (DATE/TIME)” PARAMETERS. IF YOU MISUSE THIS TRANSACTION
YOU CAN DELETE IMPORTANT DATA.
The following selection screen of SLG2 transaction could be used:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 24 von 48


3.2.3 Deleting unneeded IDOCs

Once the E4C IDOCs have been successfully processed or sent, they are not needed in the system any longer.
It is up to the Administrator whether they will stay on the system or will be archived with other IDOCs or old
E4C IDOCs will be just deleted.
The transaction WE11 can be used to delete the old IDOCs.
BE EXTREMELLY CAREFUL, NOT TO DELETE OTHER (NON E4C) IDOCS AND NOT TO DELETE THE IDOCS WHICH
ARE IN USE. BE EXTREMELLY CAREFUL TO PROVIDE THE CORRECT “CREATED ON” AND “LOGICAL MESSAGE”
PARAMETERS. IF YOU MISUSE THIS TRANSACTION YOU CAN DELETE CRITICAL TRANSACTIONAL DATA.
The following selection screen of WE11 could be used:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 25 von 48


3.2.4 Deleting Cloud Data

3.2.4.1 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:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 26 von 48


Every E4C 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.

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 27 von 48


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

3.2.4.2 Sending Deletion Requests using Send-reports

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.

3.2.4.3 Sending Deletion Requests 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).

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 28 von 48


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

3.2.4.3.1 Deleting the objects for the given identifiers

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 29 von 48


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:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 30 von 48


3.2.4.3.2 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:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 31 von 48


- Basic type: the IDoc type of the IDoc:

- Segment type: the Segment name, in which the Identifier is passed:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 32 von 48


- 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:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 33 von 48


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

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 34 von 48


3.3 Message Broker Administration
E4C was designed to use monitoring features of SAP. Thanks to that design, the Message Broker component
requires very little attendance.
The administrative activities related to the Message Broker have been collected in the sections below.
Please note, that the Message Broker is a non-SAP component of E4C. As such, you have to access the server,
where Message Broker is running with a Remote Desktop or a similar technology.

3.3.1 Logs maintenance


As already mentioned in the Error! Reference source not found. section, unless configured differently, E4C
Message Broker logs are configured to log messages on DEBUG level to files in c:\tmp\e4c.log directory.
This may cause the files grow in size very fast. As such, it is recommended to regularly check the files size vs.
available disk space.
Besides manual checks, there are the following options available to mitigate the log files growth problem:
• set the logging level to INFO or WARN in the logging configuration
• disable logging whatsoever (not really recommended)
• schedule a periodic job to compress/delete old log files

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 35 von 48


3.3.2 Starting/stopping windows services
Message Broker is installed as a Windows service. There can be several instances of E4C 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

4 Troubleshooting

4.1 Object not created in 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 Error! Reference
source not found.. 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. The description of rules and definitions can be found in E4C User Guide.
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 Error! Reference
source not found..
If the application logs do not provide any hint why the IDOC is missing, please contact your E4C
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.

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 36 von 48


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 Error! Reference source not found..
• message broker is down – you may want to verify, if the respective Windows
service is up and running as described in section Error! Reference source not
found.
• check if the web service of Message Broker is available from SAP. In order to do
that, an E4C 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

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 37 von 48


• 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 coresystems

4.2 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 Error! Reference
source not found.. If the IDOC doesn’t exist, there can be two possible reasons:
(1) the message has not been delivered to SAP by Message Broker – check if the message broker
windows service is up and running
(2) Object is blocked for transmission from cloud as dependent object has not yet been confirmed from
SAP (e.g. Activity is blocked until all confirmations like checklists, expenses, timeefforts, etc. have
been confirmed from SAP). Contact the cloudsupport who can investigate blocked objects.

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 38 von 48


5 E4C Monitoring Cockpit

5.1 Cockpit Configuration


Use E4C Menu (Transaction /PACG/EC), choose “Customizing” node and execute the “Cockpit Configuration”
transaction to configure E4C Monitoring Cockpit:

There is one record necessary:

Please enter:
• E4C technical user name
• SAP Workflow user
• Job name for processing unprocessed incoming IDOCs (SAP Standard program RBDMANI2).

5.2 Using E4C Monitoring Cockpit


Use E4C Menu, choose “Administration” node and choose “IDOC Cockpit” transaction to start E4C Monitoring
Cockpit:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 39 von 48


Alternatively use the transaction code /PACG/ECM_COCKPIT (remember to prefix the transaction name with
“/n” when executing the transaction manually).

E4C Monitoring Cockpit starts with following screen:

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

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 40 von 48


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:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 41 von 48


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 E4C queues. It is
possible to call transactions SMQ1 and SMQ2:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 42 von 48


The middle panel presents the information about E4C 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):

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 43 von 48


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

3. Show E4C 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:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 44 von 48


5.3 Email Alert for blocked queue
Working queues processing inbound & outbound IDOCs are essential – if they are blocked the communication
is interrupted until administrator could care for the root cause. In order to alert responsible persons the
report /PACG/ECM_QSTATUS can be scheduled regular batch processing. It checks the named Queues (see
also chapter 2) if status SYSFAIL is set. If true an log entry can be created in the directory and email can be
sent to inform responsibles.

It is recommended to run the report at least hourly to enable fast reaction.

6 SAP Client Copies


It is best practice to copy SAP productive client data to the test client regularly. While having both clients
connected to different cloud companies via Message Broker several steps for rebuilding the interface is
necessary.
Please note: Not completing mandatory steps below leads to situation where both SAP client communicating
with the productive cloud company(ies). This would transfer applicational data from test client to productive
data and vice versa.
There are 3 scenario:
(A) You keep the existing cloud companies and just re-create the connection from SAP test client. This
leads to situation that cloud data differs from SAP data. You can run into ID issues as cloud IDs maybe
know in SAP for different context in SAP.
(B) You ask cloud support to delete all master and applicational data in test company while keeping cloud
defined objects like Checklists, Reports, Company Settings, Screen Configurations, Cloud Actions, etc.
This allows to have initial sync after re-creation of communication for SAP testsystem
(C) You delete complete company starting configuration from scratch with fullsync.

Recommended is scenario B in terms of effort and data integrity.

6.1 Steps before Client Copy

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 45 von 48


Step Description Mandatory in scenario

B1 Save Cloud defined Objects like Checklists, Reports, Company C


Settings, Screen Configurations, Cloud Actions

B2 Stop Message Broker for all companies A, B, C

B3 Backup Configration of Service Consumer for Web Service Client A, B, C


Proxy /PACG/CO_ECMISEND_OUTBOUND_MES

B4 Request Deletion of cloud master and applicational data by B


cloudsupport. Companies should be set in Fullsync mode

B5 Delete Cloud Company using Cloud Manager Application C

6.2 Steps after Client Copy

Step Description Mandatory in scenario

A1 Correct data in transaction /PACG/ECM_CACC - Company account A, B, C


assignment

A2 Run transaction /PACG/ECM_SETUP - E4C Setup A, B, C

Common Selection Criteria:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 46 von 48


A3 Run transaction /PACG/ECM_DEL_MAPPIN - Delete Mappings B, C

Run in Batch for big cloud companies (Download > 100 MB)
Common Selection Criteria:

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 47 von 48


A4 Re-Configure Service Consumer for Web Service Client Proxy A, B, C
/PACG/CO_ECMISEND_OUTBOUND_MES

A5 Re-Create Company using Cloud Manager C

A6 Verify / Reset password for technical user in SAP which is used by A, B, C


the message broker (as it is defined in message broker
configuration)

A7 Re-Start Message Broker A, B, C

A8 Send User, Employee using send reports B, C

A9 Assign User Licenses in coresystems store to trigger fullsync B, C

A10 Re-create Cloud defined objects from step B1 C

E4C Administration and Monitoring Guide

proaxia consulting group ag Version from: 2017-11-07 Seite 48 von 48

You might also like