This Blog talks about the efforts you need to put in for the monitoring of the system to ensure the system is performing optimally.
Although I am talking about SRM here specifically, it would be same across any on-premise system of SAP which you may have installed. Ensuring you do regular monitoring is a crucial part of the support process this helps:
SRM has integration with SAP for reading accounting data as well as for PDP scenario where the Purchase requisition flow to SRM using queue mechanism. This means if any of the PR gets stuck in the transfer mechanism in SRM -ECC integration there is a high probability that the queue would be stuck and business affected if it is not monitored proactively. Activities which should be done;
Generally, execute as an Asterix condition to monitor all interfaces as seen in Figure below
You would see some entries specific to BI queue in the system which are normal and not really an area of concern from the P2P perspective as seen in Figure 154
Choose one of the below options to delete, Activate or unlock
Remember if you have an error in communication, a workflow or Batch job error then ideally it gets recorded in SLG1 if it’s a system communication error. For example, the below error in Figure shows error when transferring to the SRM system from ECC. In order to check if the transfer was successful from SRM to ECC check in both SRM and ECC to find the error message.
Example below is an error in transferring of Supplier from ECC to SRM can also be seen captured in SLG1 check the logs for program BBP_VENDOR_SYNC as seen in Figure
IDOC monitoring can be done using WE02 . Fig shows different status of IDOCs
Check IDOC Status 52 for waiting to be in processed If you refresh soon after these IDOCs may either change to green or Red. Below fig shows the ones in error and if you click on them you see the specific error message which needs to be corrected in order to process them successfully.
Another specific Transaction code for checking Purchasing document transfer to ECC system is transaction RZ20. This is used for all failed transferred POs and to get the error message for why the PO has failed. It may be possible that the SRM PO does not show any error message but it failed when it tries to transfer it to the backend in ECC due to some account assignment setting being incorrect
In RZ20 Navigate to SAP B2B Procurement – Monitors and then It would show up all the Purchase order in error status. When you click on Purchase order as seen in Figure you can find the error message in detail .
In SRM there are business rules for each object type like SC, PO, and Contract etc. However, there is a frequent issue when the approver is not determined correctly. This could be the user has no manager or the cost center owner is not yet defined. These are not really issues but something which is a general business case scenario where you need to be able to understand how to ensure these cases are identified and hence, correctly routed to the right approver. The cases where the approver could be missed to be successfully added to a purchasing document are as below
The concept of fall back agents can be utilized if no owner is found however it needs to be ensured that such POs are monitored to ensure they are routed to the right approver. This ensures that if the owner is not determined by the business logic in place then you can assign a fall back agent which could be a user group. The support team can then check and investigate further the missing approver and get in touch with the HR team to ensure the approver is maintained correctly. The kind of rules you need to maintain for the business owner not being determined can be different for each business. Below fig shows the Admin user being determined for the PO
This transaction is mainly used when you have an interface monitoring to be done. Especially if the inventory level needs to be checked or material procurement to be checked in RZ20 you would see in SRM if the material transfer failed. This transaction monitoring should be done in both ECC and SRM depending on which specific scenarios are implemented in the system.
For example, below is one of the logs captured in ECC whenever there is a change in vendor master record and it fails to be sent to SRM or update in other interfaces as seen in. It is important to make a note of any unauthorised changes in the system and helps to ensure the security of the application.
Below Figure shows Error in /SAPPO/PPO3 in authorisation. If you want to include additional authorisation or custom checks in the transaction to be recorded you can use the BADI /SAPPO/AUTH_CHECK.
If there is PI/PO/XI integration, then SXMB_MONI is one of the most important transactions that you need to use. This helps in monitoring for both incoming and outgoing payloads. Use the 1st option which is ‘Monitor for processed XML messages’ when you enter into SXMB_MONI.
Figure below shows an overall detail of the transactions and interfaces to which the system is communication with. If there is a status as “Flag” as shown below it means the successful but you can also filter for error messages and try to analyse from here why the messages were failed. It also gives important information about the receiver interface name and the timestamp can help you to pinpoint the exact document number if your sender system shows that details as well. For example, if the Contract failed from Ariba to SRM at 28.2.2017 at 12:33 then I check at exactly the same time frame in SXMB_MONI and find the error message corresponding to it so I don’t have to browse through all the incoming and outgoing payloads if the error message is not flagged specifically in the interface.
Like in every SAP system SRM is also having a lot of batch jobs to either send or receive data from the ECC system. Ensuring that these batch jobs are working as expected is very important and if they fail it could be huge issues for the business to keep up and running. Some of the batch jobs which are important and should be monitored are as below. To get the status of document updated between SRM and ECC.
Below are some additional Workflow approval jobs:
To monitor dumps in the system you can check ST22 transaction. It shows the runtime details of yesterday and today, and ideally the dump count should be very minimal with no unknown errors. If there are dumps due to timeout and refresh setting then this can be ignored rest everything should either be actioned or informed to SAP for specific OSS notes which may resolve these dumps over a period of time and improve system performance. You can open the dump and click on SAP correction notes to find the relevant note
These notes can be used to evaluate if they can be implemented. If nothing shows up then open the SAP Knowledge-based portal and search for the component version and Runtime error as shown in Figure 188. The Runtime error text can be used to find a relevant SAP Note and again evaluated if these notes can be implemented or not.
Thank you for reading the blog and I hope you find this useful
Please leave a comment or feedback if you think there is something else I should have included.
Although I am talking about SRM here specifically, it would be same across any on-premise system of SAP which you may have installed. Ensuring you do regular monitoring is a crucial part of the support process this helps:
- Improve time for your system
- Improves the user experience as you could proactively reach out to the user and inform them of the issue they would experience and help them with a workaround in advance
- Helps to reduce the number of support tickets
1. TRFCs SMq1 and SMQ2
SRM has integration with SAP for reading accounting data as well as for PDP scenario where the Purchase requisition flow to SRM using queue mechanism. This means if any of the PR gets stuck in the transfer mechanism in SRM -ECC integration there is a high probability that the queue would be stuck and business affected if it is not monitored proactively. Activities which should be done;
- Monitoring SRM Inbound and Outbound Queue.
- Monitoring ECC inbound and Outbound Queue.
Generally, execute as an Asterix condition to monitor all interfaces as seen in Figure below
You would see some entries specific to BI queue in the system which are normal and not really an area of concern from the P2P perspective as seen in Figure 154
Choose one of the below options to delete, Activate or unlock
2. SLG1
Remember if you have an error in communication, a workflow or Batch job error then ideally it gets recorded in SLG1 if it’s a system communication error. For example, the below error in Figure shows error when transferring to the SRM system from ECC. In order to check if the transfer was successful from SRM to ECC check in both SRM and ECC to find the error message.
Example below is an error in transferring of Supplier from ECC to SRM can also be seen captured in SLG1 check the logs for program BBP_VENDOR_SYNC as seen in Figure
3. IDOCs Monitoring
IDOC monitoring can be done using WE02 . Fig shows different status of IDOCs
- Status 53: All ok and nothing else is needed
- Status 52: This means that it is still under processing and will soon be green if all ok
- Status 51: These are the error which should be monitored to be sure nothing is broken
Check IDOC Status 52 for waiting to be in processed If you refresh soon after these IDOCs may either change to green or Red. Below fig shows the ones in error and if you click on them you see the specific error message which needs to be corrected in order to process them successfully.
4. Failed transferred POs using RZ20
Another specific Transaction code for checking Purchasing document transfer to ECC system is transaction RZ20. This is used for all failed transferred POs and to get the error message for why the PO has failed. It may be possible that the SRM PO does not show any error message but it failed when it tries to transfer it to the backend in ECC due to some account assignment setting being incorrect
In RZ20 Navigate to SAP B2B Procurement – Monitors and then It would show up all the Purchase order in error status. When you click on Purchase order as seen in Figure you can find the error message in detail .
5. Workflow in UWL
In SRM there are business rules for each object type like SC, PO, and Contract etc. However, there is a frequent issue when the approver is not determined correctly. This could be the user has no manager or the cost center owner is not yet defined. These are not really issues but something which is a general business case scenario where you need to be able to understand how to ensure these cases are identified and hence, correctly routed to the right approver. The cases where the approver could be missed to be successfully added to a purchasing document are as below
- Approver User ID was not created/ replicated to SRM.
- Approver is no longer part of the organisation or is not a valid user anymore.
- Sometime the user is valid but the organisation linkage is broken and hence, the record is corrupted in SRM.
- It could be possible that it is cost center driven and the owner of the cost center is not yet determined.
- There could be a logic which checks the approver roles and the user does not have the required roles.
- It could be possible to have the amount over the limit allocated for the user to approve.
The concept of fall back agents can be utilized if no owner is found however it needs to be ensured that such POs are monitored to ensure they are routed to the right approver. This ensures that if the owner is not determined by the business logic in place then you can assign a fall back agent which could be a user group. The support team can then check and investigate further the missing approver and get in touch with the HR team to ensure the approver is maintained correctly. The kind of rules you need to maintain for the business owner not being determined can be different for each business. Below fig shows the Admin user being determined for the PO
6. /SAPPO/PPO3
This transaction is mainly used when you have an interface monitoring to be done. Especially if the inventory level needs to be checked or material procurement to be checked in RZ20 you would see in SRM if the material transfer failed. This transaction monitoring should be done in both ECC and SRM depending on which specific scenarios are implemented in the system.
For example, below is one of the logs captured in ECC whenever there is a change in vendor master record and it fails to be sent to SRM or update in other interfaces as seen in. It is important to make a note of any unauthorised changes in the system and helps to ensure the security of the application.
Below Figure shows Error in /SAPPO/PPO3 in authorisation. If you want to include additional authorisation or custom checks in the transaction to be recorded you can use the BADI /SAPPO/AUTH_CHECK.
7. SXMB_MONI
If there is PI/PO/XI integration, then SXMB_MONI is one of the most important transactions that you need to use. This helps in monitoring for both incoming and outgoing payloads. Use the 1st option which is ‘Monitor for processed XML messages’ when you enter into SXMB_MONI.
Figure below shows an overall detail of the transactions and interfaces to which the system is communication with. If there is a status as “Flag” as shown below it means the successful but you can also filter for error messages and try to analyse from here why the messages were failed. It also gives important information about the receiver interface name and the timestamp can help you to pinpoint the exact document number if your sender system shows that details as well. For example, if the Contract failed from Ariba to SRM at 28.2.2017 at 12:33 then I check at exactly the same time frame in SXMB_MONI and find the error message corresponding to it so I don’t have to browse through all the incoming and outgoing payloads if the error message is not flagged specifically in the interface.
8. Batch Jobs monitoring:
Like in every SAP system SRM is also having a lot of batch jobs to either send or receive data from the ECC system. Ensuring that these batch jobs are working as expected is very important and if they fail it could be huge issues for the business to keep up and running. Some of the batch jobs which are important and should be monitored are as below. To get the status of document updated between SRM and ECC.
- BBP_GET_STATUS_2 brings updates on the shopping cart related follow-on documents updates that were made in the backend. For example, if a SC had a G/R done in ECC, that information comes over when this report is run.
- CLEAN_REQREQ_UP is used more broadly and based on a trigger from SRM. For example, whenever, there is a document (PO, GOA, etc.) created/changed in SRM, the document id is stored in
- This job checks the pending entries in BBP_DOCUMENT_TAB and makes RFC calls to ECC system to get the latest status of this document. For example, when I release a GOA from SRM, an entry gets added to BBP_DOCUMENT_TAB, and an IDOC gets created in ECC for processing. When the CLEAN_REQREQ_UP job runs, it checks the status of the contract creation in backend and updates SRM with the status.
Below are some additional Workflow approval jobs:
- SWWWIM
- SWWDHEX
- POJOB
- SWWCLEAR
- SWWCOND
- SWWERRE
- RSPPFPROCESS
- /SAPSRM/OFFLINEAPPROVALSEND: To send an email notification whenever there is an approval task for the users.
9. ST22 Dumps
To monitor dumps in the system you can check ST22 transaction. It shows the runtime details of yesterday and today, and ideally the dump count should be very minimal with no unknown errors. If there are dumps due to timeout and refresh setting then this can be ignored rest everything should either be actioned or informed to SAP for specific OSS notes which may resolve these dumps over a period of time and improve system performance. You can open the dump and click on SAP correction notes to find the relevant note
These notes can be used to evaluate if they can be implemented. If nothing shows up then open the SAP Knowledge-based portal and search for the component version and Runtime error as shown in Figure 188. The Runtime error text can be used to find a relevant SAP Note and again evaluated if these notes can be implemented or not.
Thank you for reading the blog and I hope you find this useful
Please leave a comment or feedback if you think there is something else I should have included.
- SAP Managed Tags:
3 Comments