cancel
Showing results for 
Search instead for 
Did you mean: 

Alerting of message orchestration in transactional situations

MattHarding
Active Contributor
0 Kudos

Hi All,

Just wondering if there is a standard/encouraged pattern for managing retries of BPM's within a process orchestration.  For example, a bulk extract is sent async to PO which requires a couple of web services to be called in a row (say a synchronous lookup followed by a synchronous update). Maybe the second update fails due to missing data in the called system, or the system is unavailable. We want to be able to use the standard set of alerting tools (via Sol Man) to alert either a technical user who can then clear the alert so that the service can be executed again or alternatively cancelled and manually handled.

For reference, I wouldn't want to structure a BPMN and user task around this as a solution as that would complicate the scenario unecessarily in my mind (requiring additional tasks to be populated in our UWL (which is the ERP POWL and doesn't have connectivity to BPM), and I'm hoping interim or end events (which have a type of error) would be usable.

I've tried to find something but struggling to find anything in the community or help material and for reference, I'm one of those architects who doesn't necessarily get his hands too dirty, so forgive me for not trying out a few options and providing a candidate approach. If there's a good example in the sample patterns, just point me at that.

Thanks,

Matt

Accepted Solutions (1)

Accepted Solutions (1)

ch_loos
Advisor
Advisor
0 Kudos

Hi Matt, Chris,

you can handle errors for synchronous service calls in BPM with a boundary event (this requires 7.31 SP10). See this blog for more details:

Using this mechanism you can also do automatic retries, or send alerts via email notifications.

There are existing monitors for BPM in Solution Manager, but only on an aggregated level, not on instance level. So you could define an alert if more than X instances of your particular process go into error, but you will not receive alerts for individual instances.

Best Regards,

Christian

chrismills
Explorer
0 Kudos

Hi Christian,

Thanks for your reply, having boundary events now is a massive improvement, the thing I can't figure out though is if we catch an error via a boundary events, and implement a retry flow, once this has failed multiple times how can we get the process to go to an error/suspended state so that a manual decision can be made to either resume or cancel the process via the NWA management tools without having to model this as a human action and use the BPM Inbox (or another inbox)?

If we don't handle boundary events then the whole process will go to error state if a sync call fails and can be restarted via the "Manage Processes" tool in NWA but once we handle the boundary event I'm not sure how you can get the process to an error state where it would be resumable?

Maybe I have the wrong idea about how to do this, an alternative would be to send an alert and end with a error end event but once this is done the originating message would need to be resent from the source to re-instate a new process which if you were half way through a process with many steps may not be particularly desirable.

In my most recent development I went the BPM Inbox route (retry x times, once still failing then raise a task for someone to decide if process should continue or not) but this does add a lot of error handling flow to the process and isn't ideal where a process may have hundreds or several thousand instances per day as an external system being offline and causing the processes to fail will result in a lot of tasks going in to someones inbox for resolution, plus there doesn't seem to be aggregation of email alerts upon receipt of a task so it means people receiving these will get a heap of emails too.

Thanks

Chris

ch_loos
Advisor
Advisor
0 Kudos

Hi Chris,

after let's say the third retry, you could simply go into a separate branch with an alternative version of the automated activity which does not have the boundary event. This will cause the instance to suspend with error in case of failure. Granted it will make the process model more complex.

Alerting on instance level is something we have on our roadmap.

Regards,

Christian

Answers (3)

Answers (3)

Jocelyn_Dart
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Matt, FYI ... not an answer for now but some hope for the future..

We understand the SolMan team are planning to provide APIs for just such alerting.  Don't have a date for that yet but perhaps watch out for that as that would give you an option much closer to your desired solution, and of course something we can use in other BPM scenarios as well - e.g. keep a counter and 3rd time round the boundary event, add an automated activity to raise alert in SolMan. 

Of course instance level alerting may even let us do that without complicating the process model... something we can add to the Enterprise Patterns download as well

P.S> yes I haven't forgotten your request for more in the Enterprise Patterns download... we've added the blog to the developer center - I just need to find some time to make some updates...

Rgds,

Jocelyn

chrismills
Explorer
0 Kudos

Hi Matt,

I was wondering if you ever found a good solution to this? I have much the same thoughts as you that an out of the box alerting mechanism should exist in BPM to avoid having to go down the task route, ideally something simple that covers the whole process instance and any errors that occur in it like how a component based message alert in PI can cover a whole iFlow and raise (and aggregate) alerts on any error

Having simple alerts plus a configurable number of retries on synchronous calls would be a lot nicer, as I'm finding a lot of the BPM flow is dedicated to handling errors, retries, alerting etc rather than just getting on with the job of orchestrating something.

Cheers

Chris

Jocelyn_Dart
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Matt,

Not sure I've understood your question... there is a standard alerting framework for process orchestration in single stack scenarios. Try here...

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/2c/f0a3d4540c4c9a9af65139801ef826/frameset.htm

The alert configuration is in the NetWeaver Administrator and the alerts can be consumed by Solution Manager.

Or are you looking for something more?

Regards,

Jocelyn

MattHarding
Active Contributor
0 Kudos

Hi Jocelyn,

Well let me describe just one of the situations I'm dealing with (noting I'm reviewing the solution that has been built). Basically I have a file coming in from Reuters via ftp; this contains several exchange rates. It kicks off a BPM as we need to orchestrate an update to a system called Changepoint.

Changepoint has a single synchronous exchange rate update web service.

Hence, the BPM loops through the exchange rates and updates Changepoint. If an error occurs, the current design sends a new message back to Reuters. Why you may ask? Because the thinking was that that way the message can be designed to fail and hit the standard PI alerting framework and allows the loop to continue within the BPM.

So functionally it kind of hits the mark, but logically it's pretty wrong. And even if you wanted to send the message again (since an example of an error is that Changepoint must have contiguous dates which could be manually addressed); this approach will always require a manual resolution.

I could suggest they raise a user step in a parallel task as an easy option, but that opens up requiring the use of the BPM inbox which is an option but a challenge in itself to get approval to do; so what I ideally would like is to raise the alert within the BPM, but have the option of restarting (or continuing to) the send step. Or at least just using standard alerting.

From what I can tell, the lack of BPM experience has our PI guys wanting to get back to PI as fast as possible to handle errors how they know best.

Hopefully that's not too detailed an example. My current thinking is this should be easy with a standard pattern approach, but I can't find anything on how this should look.  e.g. A picture is worth a thousand words for this question.

Cheers,

Matt

Former Member
0 Kudos

Hi Matt, not sure I'm understanding 100% correctly... but could you think of a solution without BPM?

...2 integrated configurations with several mapping steps...

  1. Create one message per exchange rate via split mapping (0..unbounded) and send messages to 2nd configuration, easiest as file
  2. Read file and do a SOAP call to Changepoint via Java mapping (SAP Help Using the Lookup API in a Message Mapping)
    • Alerts on error can either be generated in the Java mapping or via a failing SOAP message, depending on what error Changepoint returns
    • depending on the result of the 2nd step, the mapping continues and creates the target message or stops

Since it is a split mapping, only erroneous messages are stopped i 2nd scenario, others are still processed, alerts can be raised on error, and stopped messages can still be restarted manually

Regarding BPM patterns in general, I'm sure you already had a look at

MattHarding
Active Contributor
0 Kudos

Thanks for the good info Martin (though for BAU support, BPM's do tend to make understanding integration much easier than JAVA Mappings and lookup API's). And yep - Generally we do avoid BPM where it is appropriate to do so, but in my case, the example was more one scenario where BPM has been used by the System Integrator, but it seems they are not managing any alerts in BPM, or if they do, they do via message sending in PI. Logically, an error in BPM should be alerted within BPM - that's my argument, but not sure what standard practice is to do this.  Maybe it's a question for the CE folk, but I'm guessing they jumped straight to User Steps to fix it.

Cheers,

Matt

Former Member
0 Kudos

There is a sap standard wsdl called AdapterMessageMonitoringWsdl which can be used for the interface monitoring. You can find it in WS navigator. However you do have to build a db table or something similar to maintain the status of each interface run. Notification email to users can be triggered by checking the table.

It can also be developed as a generic framework which can be used for monitoring purposes.

MattHarding
Active Contributor
0 Kudos

Thanks Bai - That sounds like a good solution, but searching for AdapterMessageMonitoring really doesn't instill me in confidence that this as a well known/documented solution that I can point my System Integrator at without them doing a lot of prototyping. Would love it if you get a chance to blog about your use of this as it does sound hopeful.  That said, still think you shouldn't need to leave BPM just to raise an alert to the overall error framework (maybe I expect too much!).

Cheers,

Matt

Former Member
0 Kudos

Hello Matt,

The reason why I didn't document this process is that this tool is not recommended by SAP due to the memory consumption issue. However I haven't faced this issue in our PROD environment. Maybe it is because we only use it to monitor the business critical interfaces which are very few at the moment. Please see Note 1486734 - Problems Using AdapterMessageMonitoringVi for more details.

In our scenario, we do use BPM to run this proactive alerting process. We have db table to record the batch run time and time interval of critical interfaces every day. The interface checks the entry in the table and send to BPM. In the BPM, it transforms entries from table to webservice call (we use getMessageList() WS in this wsdl). If BPM successfully receive the response message, that means the interface has already run. Otherwise that means the interface fails to run at a scheduled time.

Don't think you can achieve it without BPM but you can give it a try. I didn't spend too much time on other methods in the webservice document. It may be useful for the monitoring process as well. At least this is a much more formal process for monitoring purpose.

You can find it and test the webservices by searching the keyword in WS Navigator as shown in the following screenshot.

Attached is the screenshot of all the methods of wsdl file you can use. I haven't migrated this interface to PO 7.31 single JAVA stack yet but I believe there shouldn't be any technical issues around implementation and this wsdl is also available in the new PO system.

Feel free to ask me any questions and let me know how you go.

Regards,

Bai

adityavempati
Participant
0 Kudos

Hi Bai,

I am trying to build an interface using getMessageList webservice. Before doing it I just want to test it in SOAP UI tool. But, when I trigger a call I am getting a fault response (mentioned below).

Deserializing fails. Nested message: XML Deserialization Error. Empty node passed to deserializer [com.sap.engine.services.webservices.jaxrpc.encoding.primitive.DateTimeSD] which is not acceptable

I raised a thread for this: http://scn.sap.com/message/16063858

Could you please check and provide your inputs.

Regards,

Aditya Vempati