Fault (common, standard) and Fault Handling Framework (Occurs during invocation time)

What is error or fault?
We say there is error or Fault means when we didn’t receive expected response.

How many types of faults we can have in SOA Suite tool?.
We categories fault into 2 categories.
1. Business Faults
2. Technical Faults

What is Business Fault?
As the name suggest, these faults related to business scenarios. These errors are thrown explicitly in code by us. E.g. we have written the functionality to do card validation but do card number check if card number comes blank then we throw business fault and reply back to user with same response.

What is Technical Fault?
Faults other than business faults known as technical faults. There may be many reasons for these technical faults like code break, connectivity error, Invalid message etc. But mostly we receive connectivity errors under technical faults.

Can we define our own faults?
Yes, we define our own faults in SOA Suite tool, we generally created fault for business fault scenario where we explicitly throw error.

What steps we need to follow to create custom error?
We need to follow below steps to generate custom error.
1. Define XML structure for fault message.
2. Create message based on that XML structure in WSDL.
3. Associate that message in WSDL operation.

Which activity we use to throw business fault in BPEL?
We use throw activity to throw business fault.

What is difference between Remote and Binding fault?
We receive remote fault when we have connectivity issue while connecting to reference systems/applications. We receive binding fault preparation of the invocation fails. For example, the WSDL of the process fails to load. A binding Fault is not retryable. This type of fault usually must be fixed by human intervention.

How we can handle faults in SOA Suite tool?
We can handle faults by 2 ways in SOA Suite tool.
Using Catch & CatchAll blocks
Using Fault Handling Framework

How catch & CatchAll blocks work?
We use these blocks to handle the fault in BPEL component. We can’t use these blocks in other components to handle the fault. We can apply these blocks to main BPEL process or we can also apply at scope level as per our requirement.


What is the difference between Catch & CatchAll block?
Following are the difference between Catch & CatchAll block.

Catch block
1. This is used to handle specific fault
2. Store fault information in fault variable
3. We can add more than one Catch block in one BPEL process.

CatchAll block
1. This is used to handle any type of fault.
2. We need to use functions to get the fault details.
3. We can add only on CatchAll block in one BPEL process.

Which function we use to get Fault Name and Fault description in CatchAlll block?
We use ora:getFaultName() to get fault name and ora:getFaultAsString() function to get fault description in CatchAll block.

What is Fault Handling framework?
Oracle SOA Suite provides generic (common, standard) fault management framework to handle the faults. We use this framework to handle the fault that occurs during invocation time.

What is the difference between Catch blocks and Fault Handling Framework?
Following are the difference between these two.
Catch & CatchAll Blocks
1. We use Catch & CatchAll block to handle all types of error.
2. These can be used only for BPEL component.
3. We can use this for all 3 BPEL templates (Sync, Async, Oneway).

Fault Handling Framework
1. We use this framework only to handle invocation faults; we can’t use this framework to handle all types of fault.
2. This can be used for BPEL as well as Mediator component.
3. We should use this only for 2 BPEL templates (Async and OneWay).

How Fault Handling Framework works?
Fault Handling Framework is based upon two files.
Fault-policy.xml: This file is used to define one or more fault policies with conditions and actions.
Fault-binding.xml: This file is used to associates a policy with a composite, component or reference.

Where we keep these two fault-polic.xml and fault-binding.xml files?
We keep these files either local to our project or in MDS. We need to specify the path of these files in composite.xml file when we keep these files in MDS.

Can we define more than one policy in fault-policy.xml file?
We can have more than one policy in fault-policy.xml file and each policy will have its unique id.

What all actions we have in fault-policy.xml file?
We have following actions in fault-policy.xml file.
1. Retry
2. Human Intervention
3. Terminate
4. Java call
5. Replay
6. Rethrow

How we handle errors in mediator component?
We use fault handling framework to handle fault in mediator as in mediator we get only one type of fault.

What is file rejection handler?
File rejection handler is used to handle rejected file while performing polling.

What all types of rejection handlers we have?
We have following types of rejection handler in SOA Suite tool.
1. Web Service Handler
2. Custom Java handler
3. Queue handler
4. File Handler

What is Web services and what they do.? Types of Web services.?

Web service is a standardized medium to propagate (transmit or spread) communication between the client and server applications on the World Wide Web.

A web service is a software module which is designed to perform a certain set of tasks.
The web services can be searched for over the network and can also be invoked accordingly.
When invoked the web service would be able to provide functionality to the client which invokes that web service. Web Services Revealed

Web services are part of the Services Oriented Architecture. Web services are used as the model for process decomposition and assembly. I have been involved in discussion where there were some misconception between WEB SERVICES and WEB API.

The W3C defines a Web Service generally as:
1. A WEB SERVICES is a software system designed to support interoperability machine-to-machine interaction over a network.
2. Web API also known as Server-Side Web API is a programmatic interface to a defined request-response message system, typically expressed in JSON or XML, which is exposed via the web – most commonly by means of an HTTP-based web server.


Question
When to use SOAP and when to use REST?

1. Rest is based on http protocol (get, put, post, delete) , treating everything as a resource, whereas SOAP is transport agnostic
2. Soap works only with xml, Rest works with json/xml both.
3. Rest do not provide schema definition when implemented as JSON, Soap will always provide schema definitions.
4. It will be easy to understand request/response schema and their data type constraints when viewing schema information via WSDL by any client.
5. The step of wsdl creation makes it difficult to make any changes in your schema classes while implementing in soap. Rest implementation is quite easy; we just need to make changes in pojo classes.
6. Soap provides default error handling via faults. We can also create our own custom faults.
7. In Rest we need to handle all error messages explicitly.
8. Soap provides SoapHandler to intercept request both at client/server side with both request/response. We can use filters of j2ee or interceptors of Spring to intercept calls.
9. Soap is fixed defined set of protocol, whereas rest is architectural style. While implementing REST, developers can follow any rule,

For example
Not using http protocol in well-defined way. While in Soap message part is defined as envelope.
One envelope=header+body+fault+attachment

Use REST for

1. Totally stateless operations: If you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it
2. Caching situations: if the information can be cached because of the totally stateless operation
3. Limited bandwidth: SOAP XML response consumes more bandwidth compared to REST response


Use SOAP for

1. Asynchronous processing and invocation: if your application needs a guaranteed level of reliability and security
2. Formal contracts: if both sides (provider and consumer) have to agree on the exchange format
3. Stateful operations: if the application needs contextual information and conversational state management

Remember

HTTP binding uses Verbs (Get, Post i.e. Retrieve/Reading, Insert/Writing). 
REST binding uses HTTP Verbs (Get, Put, Post, and Delete Method i.e. Retrieve/Reading, Update/Editing, Insert/Writing, Delete/Removing). 

Web services versus API

Whats is the difference between API and Web services? 

1. API and Web service serve as a means of communication. 
2. The only difference is that a Web service facilitates interaction between two machines over a network. 
3. An API acts as an interface between two different applications so that they can communicate with each other. An API is a method by which the third-party vendors can write programs that interface easily with other programs. 
4. A Web service is designed to have an interface that is represented in a machine-processable format usually specified in WSDL. Typically, “HTTP” is the most commonly used protocol for communication. Web service also uses SOAP, REST, and XML-RPC as a means of communication. 
5. API may use any means of communication to initiate interaction between applications. 

For example, the system calls are invoked using interrupts by the Linux kernel API.

An API exactly defines the methods for one software program to interact with the other. When this action involves sending data over a network, Web services come into the picture. An API generally involves calling functions from within a software program.

Summary:

1. All Web services are APIs but all APIs are not Web services.
2. Web services might not perform all the operations that an API would perform.
3. A Web service uses only three styles of use: SOAP, REST and XML-RPC for communication whereas API may use any style for communication.
4. A Web service always needs a network for its operation whereas an API doesn’t need a network for its operation.
5. An API facilitates interfacing directly with an application whereas a Web service interacts with two machines over a network.
6. Web service is like advanced Urls and API is Programmed Interface.
7. API contains classes and Interfaces just like a program.
8. A web service is a form of API (Application Programming Interface).
9. An API is used by a computer programmer to establish a link between software applications. This interface can take several forms, a web service is just one of these.
10. There are several types of web service. SOAP (Simple Object Access Protocol) is one of the most common. The API takes the form of a service description (WSDL) which is used to automatically generate the program code which makes the connection.

 Cheers..!!

XQUERY versus XSLT; which one is best?

SOA Suite clearly supports XSLT better where as OSB supports both XQuery and XSLT.

But question arises when to go for XSLT and when for XQuery ...!!

So the best answer is

If you have LARGE Messages and transformations on every element, XSLT might perform better because at runtime whole XML document is loaded in memory when using XSLT while XQuery loads the objects in memory depending on each statement.

But nn the other hand if doing a transformation on a large object but using only a FEW Elements out of BIG XML it would make sense to use XQuery instead of XSLT.

One factor in favor of XSLT may be that being an XML you can generate scripts to dynamically generate XSLTs, but it would be much tougher to generate an XQuery dynamically, although use cases for this scenario are very few (usually migration utilities etc).

What is a XA and Non-XA data source in SOA Suite?

An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).

XA and Non XA are transaction protocol for a JDBC data source that determines how the connections are handled from a data source during any transaction.

XA data source In simple term XA datasource supports “global transaction”. It supports two way commit operation. Let’s understand this with an example:

Requirement:
Oracle OSB Proxy service updating more than one database table using update query as shown below example.


If all the three queries are dependent on each other and any of the three query gets failed while updating table then the whole transaction will be rolled back.

So this is a “global transaction”. If we “commit”, it will do commit across all the resources and “rollback” will revert all of the resource’s updates done in the transaction.

Conclusion: It has transaction coordinating manager that allows handling multiple requests.

Non XA data source:
In simple term Non XA datasource supports “single transaction”. Non XA transaction always commit/rollback single resource/operation.

You can compare Non XA as simple jdbc call in JAVA, we will create one connection and update table than finally release connection for particular query. Let’s understand this with an example:

Requirement:
As per above image, if we want to update all the queries independently, we need to create data source support Non XA transaction.

Conclusion: It has no transaction coordinating manager that’s why it can handle one request at a time.

Comparison:
1. XA datasource support global transaction, so it requires less database transaction compare to Non XA datasource.
2. If you got multiple requests at a time, there might be a chance of getting Non XA connection pool full and causing failure.