Saturday Jan 30, 2016

Simplifying Error Handling with Custom XPath Function by Dan Reynebeau

clip_image001How many times have you developed error handling logic in a BPEL process and want to collect error information to pass to an error handler service?  There are many xpath functions that are currently available and can be utilized individually to collect all the necessary data, however this can become a time consuming task when you have several catch blocks and many processes.  This is a case where re-use is a must.  Simplifying the collection of the error data will ensure that the error handling is completed and performed in a consistent manner across processes.

Re-using the logic doesn’t imply copying the logic to another process, this leads to maintenance problems since we will inherently forget every place it was copied.  You could create small utility BPEL processes that manage the logic but that can be a bit heavy weight and probably overkill.

Custom XPath functions come to the rescue and solve this problem by providing a framework to generate a custom java class that can perform the collection of all the error data and return a XML document in the structure of the specific error handler.

Now we know we want to create a custom XPath function to populate the following CommonErrorHandler.xsd, so here are the steps required. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Friday Jul 31, 2015

BPM 12c Advanced Error Handling and Recovery – Part 1 by Antonis Antoniou

clip_image002Introduction

The ability to handle exceptions and recover from errors is fundamental to implementing reliable and robust business processes and enterprise systems.

There might be cases, though, when an unexpected problem occurs during the runtime lifecycle of a process that will cause your process to fail. This could be the result of a connectivity loss, a failure in a database connection, a selection failure, or a failure during an invoke activity. These types of errors, referred to as systems errors, arise directly from the underlying software or hardware infrastructure where the BPMN Service Engine is running.

There might be cases when business faults occur. These are application-specific faults that are generated when there is a problem with the information being processed (e.g., a stock control and inventory service throwing an error when a stock item is not found). Business faults are a more “controlled” fault type since you are aware of its plausible appearance; it can occur only if your application executes a THROW activity or your invoke activity receives a fault message response.

However, despite their essentialness, error handling and recovery are often overlooked in Business Process Management (BPM) projects. Analysts tend to model exception handling (mostly system or rare business faults) in the BPMN, making process design very complex, and very difficult to read and follow—resulting in skyrocketing maintenance efforts.

The new release of Oracle BPM Suite 12c introduced some really nice new error handling and recovery features. And even though I am tempted to just put on my developer’s hat, I cannot ignore the importance of the fundamental improvements Oracle has made in error recovery, from an operations and management perspective.

This two-part article will compare the differences in fault handling options between 11g and 12c and will explore the new error handling and recovery features introduced in Oracle BPM 12c from both a developer’s angle (part 1) and an administrator’s perspective (part 2).

Main

Force Commit After Execution

One of the new developer-oriented error handling and recovery features in Oracle BPM 12c is the “Force commit after execution” option (see Figure 1, below). This option configures activities, events and gateways to explicitly force BPM runtime to add a checkpoint in the dehydration store, committing the state of the BPM instance after their execution.

This important new feature lets developers explicitly force dehydration during process execution to avoid re-executing non-idempotent activities in case an error forces the transaction to be rolled back.

Let’s take, for example, the loan initiation process. A customer requests a loan and the system exports the loan application into an xml file before persisting the loan application data into an operational database (see Figure 2). Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Friday Feb 20, 2015

OSB12c: Errorhandling in REST by Martien van den Akker

clip_image002Yesterday, I had an OSB consulting day at a customer. We looked into a REST service that was to be extended with update functionality. Since calling an update service of an EIS (Enterprise Information System) can go wrong with all sorts of errors, it is important to be able to return a fault-message with the errors, jason format.
Now in OSB12c it's very apparent how you define possible fault-messages and even how the should be formatted in JSON:

In this sample case we created a more or less simple xsd for faults (dutch: fouten). To test with different fault messages we simply duplicated the 'fouten' element in the xsd to 'fouten2'. You can assign different HTTP-status codes to the different fault.
So this is configuration is pretty simple and straight forward. But it is not quite clear in the documents how you would return a specific fault within your error-handlers in the pipeline.
Internally OSB works not only 'XML'-based but actually SOAP-based. So the trick in the end is to replace the body with a soap-fault message and the selection of the REST/JSON errormessage is done based on the structure of the document in the details-section of the SOAP-Fault. In the screen above, you would define for each fault message an xsd-element and apparently it validates the soap-fault-details content against each XSD defined, and the xsd against which the detail-content is valid points to the returned fault, with the corresponding HTTP Status.

Read the complete article here

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Thursday Dec 13, 2012

Fault Handling Slides and Q&A by Vennester

Fault Handling
It is one thing to architect, design, and code the “happy flow” of your automated business processes and services. It is another thing to deal with situations you do not want or expect to occur in your processes and services. This session dives into fault handling in Oracle Service Bus 11g and Oracle SOA Suite 11g, based on an order-to-cash business process. Faults can be divided into business faults, technical faults, programming errors, and faulty user input. Each type of fault needs a different approach to prevent them from occurring or to deal with them. For example, apply User Experience (UX) techniques to improve the quality of your application so that faulty user input can be prevented as much as possible. This session shows and demos what patterns and techniques can be used in Oracle Service Bus and Oracle SOA Suite to prevent and handle technical faults as well as business faults.

Q&A
This section lists answers to the questions that were raised during the preview event.
Q: Where can retries be configured in Oracle Service Bus?
The retry mechanism is used to prevent faults caused by temporary glitches such as short network interruptions. A faulted message is resend (retried) and might succeed this time since the glitch has passed. Retries are an out-of-the-box feature that can be used in Oracle Service Bus and Oracle SOA Suite using the Fault Policy framework. By default, retries are disabled in Oracle Service Bus. Read the full article.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit  www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Mix Forum

About





Search

Archives
« May 2016
SunMonTueWedThuFriSat
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
    
       
Today