E4C Administration and Monitoring Guide
E4C Administration and Monitoring Guide
Your Contact
Telefon: +41 56 4182080
Email: [email protected]
Web : http://www.proaxia-consulting.com
2 E4C 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:
The transaction WE10 can be used if we want find the IDOCs for the given type and object.
Example:
Once the IDOC has been successfully sent to the Cloud, it should have the status 41:
01 The IDOC has been created (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
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).
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:
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)
To see more details you should double click at the status 53:
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).
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.
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.
The logs of the application can be viewed with the following call of SLG1 transaction:
Once you execute the transaction the logs for the given period of time will be presented:
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.
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
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
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:
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.
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).
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.
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:
(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):
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:
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:
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:
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.
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).
4 Troubleshooting
03 Status 03 indicates, that the IDOCs have not been sent to the Message Broker
component. This may happen because of the following reasons:
• 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
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
Please enter:
• E4C technical user name
• SAP Workflow user
• Job name for processing unprocessed incoming IDOCs (SAP Standard program RBDMANI2).
There is a navigation panel for choosing the given company or all companies in the top left area:
In the IDOC Part click one of 24 buttons to analyze IDOCs for example:
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:
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:
Run in Batch for big cloud companies (Download > 100 MB)
Common Selection Criteria: