on 08-18-2014 6:26 AM
Hi evreyone,
I need to send an email to the requester of change request in SAP MDG F when the data replication of change request is successful. How can I capture the Change request status when the data replication is successful. Is there any way to identify the same. Please provide me the steps.
Thank you.
Regards,
Anusha
Hello,
There are two types of notifications: notification that a user has something in their inbox that they need to act on (approve, process, etc.), and a notification that something was completed successfully or unsuccessfully (replication successful, replication failed, etc.).
For the first one (something that they need to act on), you can (and should) use "Extended Notification" as Sanjay suggested. For the second one (something was completed, failed, etc.), you can use the document that Kiran suggested.
However, please review the requirement again. Do you really need to notify the user that something was done successfully? Well, it is supposed to work successfully any way. You typically notify users of problems or errors so they can take corrective action. It sounds nice when you are designing & implementing the solution to build all sorts of notification. Think about the end user's inbox after go-live when their inbox is full of unnecessary notifications. Everybody will come screaming at you to turn the notification off. Many users will create rules to delete those notifications and hence they could miss on important things if something really needs their attention.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Kiran and Abdullah,
I liked your comment. As I understand about the doc Kiran sent that an email notification can be sent when a change request is approved. But here is my question for you two.
When a change request is approved, does this really mean that the replication (next step after CR got approved) to this change request will happen successfully in ECC to update various ECC tables, i.e. CSKS and Cost Center Hierarchy structure successfully?
Our unique requirement is that we need to sent out an email notificdation when replication has lead into a good result in ECC and when replication has lead into a bad result in ECC. Good result in ECC = ECC tabel/structure is updated correctly= new master record created or changes are made. Bad result = ECC table/structure is not updated = new master record did not go into ECC table or structure.
What is the best way to leverage the solution presented in the doc Kiran sent to meet our requirement? In our case, we care about the replication result as far as the master record add/change/delete is concerned from ECC perspective and we don't care of the change request approval as we thought that even if a change request is approved, the data replication may fail next and an email notification to inform user is necessary.
Please advise.
Thanks,
LUO
I would like first to make a couple of assumptions:
Now, having said that, the way I look at is as follows:
If activation fails (most probably due to business error), business users need to be notified. If replication fails after a successful activation (most probably due to technical error), the interface team needs to be notified. So, while MDG notifications might be needed for activation errors, replication errors should be handled the same way any failed interface is handled (not through MDG). The interface team usually have their own set of monitoring tools that they can (and should) use when MDG replication fails.
I agree that business rules are the same between MDG and ERP but the reaction from each systems is rather different. In ECC, If there is an data entry error that this is a violation of business rule, the screen would shop right there. that way, folks would get to know this is not happening becasue of whatever the issue is. Now in MDG, the reaction is not as interactive as ECC. this is the gap I want to fill. I also agree to your point that replication errors should be handled through Interface team. Could you share some information about how Interface team handles the error within your organization? how they are monitoring the replication results with xxx tool. Please.
You are correct; MDG interaction is different. However, business rule errors should up as activation errors and not as replication errors. Thus, in your workflow definition, you should send CR's with activation errors back to business users. Once activation is successful, the assumption is that it is just a technical step to replicate the data to the target systems (be it ERP or any other system). Now, if the replication fails, then your interface team should handle it. Handling errors depends on your interface infrastructure. Do you use IDOCs? Do you use Web Services? Do you use SolMan to monitor interfaces? Do you use PI? Do you use other monitoring tools? The answer is very specific to each landscape.
Hi Luo,
As Abdulla mentioned, each Integration Server provides features to handle errors and successful message transfers. Incase you are not using any integration system and distributing data directly from SAP MDG to target ERP system, you can utilize the Reconciliation IDOC infrastructure.
Regards,
Kiran
Great! What interface team can do if SOA Web Service is engaged in my implementation? The other thing I want to ask is that as far as I know it has proven that even though Replication result is showing successful in Replication Log, however in its further downstream data process into ECC, it can still errors out when data is coming out of SOA and going into ECC. Is that true? If so, my requirement is not looking at SOA replication log as this is not telling me the final result, I am rather looking into ECC to say "it is Successful" if a new master data record is actually created in ECC table/structure or a changed master data record is updated in ECC table/structure. If I want to go with that path, what else can I do?, Am I over engineering?
Thanks,
LUO
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.