Fault Handling and Prevention - Visualpath

1. Fault Handling and Prevention - Visualpath Introduction It is one thing to design and code the "happy flow" of your automated business processes and services. It is another thing to deal with unwanted, unexpected situations that might occur in your processes and services. This article, the first in a four-part series, will dive into fault handling and prevention in an environment based on Service-Oriented Architecture (SOA) and Business Process Management (BPM) principles. You will learn about the different types of faults that can occur and how fault handling in an SOA environment differs from fault handling in traditional systems. We will investigate what can go wrong in such environments based on a case study of an Order-to-Cash business process. For each of these problems you will learn about the out-of-the-box capabilities in Oracle Service Bus and Oracle SOA Suite that can be applied to prevent faults from happening and to deal with them when they do occur. What is fault handling? A fault can be defined as something that is unusual and happens outside the normal and expected operational activity or "happy flow" of a process. Faults in IT-systems can be categorized into the Following types: Technical errors - Faults caused by errors in the underlying infrastructure or middleware components on which applications run. Examples are network errors, server failures, corrupt disks, full tablespaces, and so on. Software errors - Faults caused by programming errors in custom-made applications, faults in 3rd party software libraries that are used, software faults and bugs in packaged applications, etc. Think of division by zero, infinite loops, memory leaks, null pointer exceptions, and so on. Faulty operation by users - Faults caused by human errors when using IT-systems. Examples of such faults are entering a wrong credit card number, accidentally switching the to and from date when booking flight tickets, ordering the wrong eBook in a web shop, and so on. Exceptional business behavior - Faults caused by a failure to meet a certain business rule. For example, a customer with a bad credit rating, a new customer that wants to purchase something but is unknown in the CRM system, an invoice with an incorrect invoice amount. Compared to "business-as-usual" it is expensive and time-consuming to deal with faults since fault handling often involves human work and expertise: the CRM department might need to call a customer, IT-operations might need to increase tablespaces, the financial department might need to compare statements of works and invoices, etc. etc. Fault handling should therefore focus on prevention first: Technical errors can be prevented by installing and configuring infrastructure and middleware in a robust and (possibly) redundant fashion. Hardening and active monitoring help to maintain quality of the infrastructure. Software errors can be prevented by applying software development methodologies and best practices such as pair-programming, collegial reviews, and test-driven development. Faulty user operations can be prevented by applying good User Experience (UX) techniques and methodologies so that IT systems are well designed, easy-to-use, and that applications provide the information that users need.

2. Business faults can be prevented by clearly specifying to stakeholders what conditions apply. Stakeholders can be customers, suppliers, employees, and so on. However hard we try though it is impossible to prevent all faults from happening. When faults do occur it is important to detect them and have effective fault handling measures in place to deal with, and recover from them. Don't just ignore faults and hope nothing bad happens. The differences between these approaches are shown in the following comics from Geek and Poke Fault Handling in SOA versus Traditional Systems The goal of every developer should be to create unbreakable systems. The extent to which that goal can be achieved depends on the success of efforts to handle and manage expected and unexpected exception conditions. Object-oriented languages such as C++ and Java provide an efficient way for handling exceptions using constructs such as try, catch, and finally. In a SOA most of what is available at language level is still valid and usable for creating elementary services. However, SOA raises different challenges when orchestrating services and creating composite applications. Figure 1 illustrate a typical SOA and BPM environment. This environment includes: Providers of services. Services that an organization uses are provided by internal systems and applications such as packaged applications, commercial off-the-shelf (COTS) software, custom-build applications, client/server applications, and other software components. External organizations can also act as service provider; consider a trading partner that offers invoicing services. Exposed services. The functionality of service providers is exposed as small building blocks that provide well described functionality that is easily accessible; i.e. services. Services can be exposed through an intermediary such as an Enterprise Service Bus; although this is not necessarily the case. Consumers of services. The services that you expose are used by a variety of consumers. The services can be offered to your trading partners such as suppliers and customers (external). Services can be orchestrated together with manual activities into business processes that your organization implements. This can be achieved using BPM or Case Management platforms. Finally, user interfaces such as Portals and Mobile Devices consume services to enable end users to do their jobs. User interfaces typically also interact with BPM and Case Management platforms so the manual tasks that need to be executed are visualized together with the information that end users need to complete these tasks. Figure 1: Typical SOA and BPM environment The following aspects of such an environment have an impact on the way you should implement fault prevention and handling: Services can be asynchronous or fire-and-forget, and processes might be long-running. This means that work is not executed in a single transaction that can be rolled back. You need other mechanisms to undo changes. Services and processes contain timed events that might or might not occur. You need to guard that such events occur within a certain time-period, or that messages don't get lost so that process instances are not waiting forever.

3. Services are autonomous building blocks with their own functionality and should not be dependent on other services. Whenever possible, faults should be handled in the service in which they occurred. Services are used in larger units of work, such as composite applications and processes. Fault recovery should also be addressed in a similar scope, beyond that of an individual service. There are multiple service consumers, often also outside your own organization. You cannot implement fault handling logic that is specific to only one service consumer. The logic should be applicable for all (future) consumers of the service. Typically, a SOA environment consists of heterogeneous and external components, which lends even greater important to standards for fault handling. In the rest of this article—and in subsequent articles in this series—you will learn what patterns and out- of-the-box features can be used to implement effective fault prevention and handling in a SOA- environment. Scenario In parts two and three of this article series we will delve into the fault prevention and fault handling capabilities of the most important SOA building blocks of Oracle SOA Suite: the SCA infrastructure (with its service components such as BPEL and Mediator) and Oracle Service Bus. We will present these capabilities using a scenario that is complex enough to show some real-life error situations. Figure 2 shows this scenario, an order process that is implemented on Oracle SOA Suite 11g. We are using the Trivadis integration blueprint notation, as presented in Service Oriented Architecture: An Integration Blueprint [See Sources]. The left side shows the process steps from the moment where the order request is received until the order is processed. The right side shows all the external systems that the process application interacts with to complete orders. Such systems include the application in which clients can order products, two different credit card service providers to bill clients, a product database, the order processing application, and a history service to store completed instances of the process. The middle lanes show the integration of the process with the backend systems using services that are invoked from the process and exposed by Oracle Service Bus 11g. Fault Prevention and Recovery Strategies Various patterns can be applied to prevent faults from happening or to handle them when they cannot be prevented. The following table lists patterns that improve the fault prevention and handling capabilities of your software. These patterns should be seen from the perspective of the service provider. In other words, in order for services to provide added value and good quality-of-service, the service provider is responsible for implementing the fault handling patterns. Thereby relieving the service consumers from this task. For more information Click Here Contact us: 9989971070