OSB 11g: Alert and Alert Destination in oracle service bus

Oracle Service Bus enables you to monitor and collect run-time information required for system operations. This post explains the steps to use alerts in Oracle Service Bus. Alerts are used inside message flow to generate an alert and that alert we can see in OSB console. To generate an alert in message flow, we use alert activity and each alert activity is linked to alert destination.

When we use alerts in OSB, for each alert we need to define alert destination i.e. we need to define the destination of the alert.  In OSB in alert destination we can perform below two functions.

• Send email
• Send message to JMS queue/Topic

To create an alert destination, click on resources folder and choose “Alert Destination” from resource type drop down list.

Specify the alert destination name and click on add button as we send alert message to JMS queue.

Take special care while specifying queue Endpoint URI.

Jms://host:port(,host:port)/FactoryJndiName/DestJndiName

FactoryJNDIName

It is JNDI name of Connection factory, if you are using default connection factory then this will be equal to “Weblogic.jms.XAConnectionFactory” and if you are using any custom connection factory then you have to mention connection factory JNDI name.

Let’s suppose you are using below connection factory for your queue.

Connection Factory Name- SampleCF

JNDI- jms/SampleCF

Then your FactoryJNDIName will be “jms.SampleCF”.

DestJndiName

It is JNDI name of JMS queue. We are following JMS queue.

JMS Queue- SampleQueue

JNDI – jms/SampleQueue

So our DestJndiName will be “jms.SampleQueue”.

Now your alert destination should look like below.

You can also add email recipients if you want to send a notification in case of alert. For that you need to click on Add button.

Mail Recipients field: In this field enter an e-mail recipient in the format: mailto:username@hostname

This is a required field.

You can specify multiple e-mail recipients by entering the user names and hostnames in a comma-separated list. For example,mailto:username@hostname [,username_1@hostname_1]...[,username_n@hostname_n]

Only the first mail recipient needs to be prefixed with the text "mailto:".

SMTP Server field: select the name of the SMTP Server for the outgoing e-mail. This field is not required if a mail session is selected in the next step.

Mail Session field: select an available mail session. This field is not required if an SMTP Server is selected in the previous step.

From Name field: Provide a sender's name for the alert notification. This field is optional.

From Address field: Provide a valid e-mail address. This field is required if a value for "From Name" field is specified.

Reply To Name field: Provide a name to which a reply may be addressed. This field is optional.

Reply To Address field: Provide an e-mail address to which a reply may be sent. This field is required if a value for "Reply To Name" field is specified.

Connection Timeout field: Enter the number of seconds a connection must wait for a response from the server before timing out. The default value is 0.

Request Encoding field: Enter a character set encoding value. The default encoding value is iso-8859-1.

Specify all these values and save your alert destination.

Now go to proxy service message flow and add an Alert activity to generate the alert. To add an alert activity, go to Reporting à Alert.

Click on destination link and choose earlier created alert destination.

Click on expression and specify fault context variable since we have added this alert in error handler but you can pass any context variable in the alert as we send this fault message to alert destination.

Also choose the level of severity from drop down.

These alerts you can see in OSB console and whatever action you choose in alert destination, that alert message will flow there.

XPath, XQuery and XPointer

Difference between XPath, XQuery and XPointer ?

XQuery stands for XML Query Language. That already tells the essence. It is a language to select subsets and substructures from a large set of XML files. The result can be manipulated into something that is suitable to be used in, for example, a subsequent process, or to show in a web browser. XPath is used a lot in XQuery.

All XML standards have their own scope. I’ll name a few.

XSLT is a language for transforming XML into some other format.

XPointer is an extension of XPath to address nodes more accurately within XML fragments or even subparts of nodes.

XLink is a standard to define relationships.

XInclude is a standard to compose multiple pieces of XML into one using for instance XLink relationships.

XProc is a standard with which can be described how XML documents should be processed to get to a desired end result.

It is expressed itself in XML, and describes the process step by step, also called XML Pipelines. Within XProc you use a.o. XQuery, XSLT, and XInclude languages (and thus indirectly XPath, XPointer and XLink as well) to express what needs to be done exactly within each step.

XQuery vs XPath

XQuery is a functional programming language that is used to query a group of XML data. It is able to manipulate and extract data from either XML documents or relational databases and MS Office documents that support an XML data source. It is a language that helps in creating syntax for new XML documents. XQuery is represented in the form of a tree model with seven nodes, namely processing instructions, elements, document nodes, attributes, namespaces, text nodes, and comments. All values are referred to as sequences. Even a single value is considered as a sequence of length one. The sequence can consist of either nodes or atomic values like integers, strings, or Booleans. It has the following features that are used for the transformation of XML data:

Side effect free.

Logical/physical data independence.

Strongly typed.

High level.

Declarative.

XPath is the XML Path Language that is used for selecting nodes from an XML document using queries. It can also compute values like strings, numbers, or Boolean type from another XML document. The expression in case of XML is known as XPath. It is represented as a tree structure with the ability of XPath to navigate it by selecting different nodes. It was created to define a common syntax and behavior model for XPointer and XSLT. XPath has the following features:

XPath defines the syntax for an XML document.

It has the capability to navigate path expressions in XML documents.

It has its own library defining standard functions.

It is a major component of XSLT.

Other differences between XPath and XQuery:

1. XPath is viewed as a regular expression whereas XQuery is like a C-programming language w.r.t. XML documents.

2. XPath is a filter for an XML dataset and is the transformational component of XSLT. XQuery is used to select several nodes from an XML document for the purpose of processing using different queries.

3. XQuery uses XPath syntax for addressing different parts of an XML document. The joins are performed using the FLWOR expression. This expression has five clauses, namely, WHERE, ORDER BY, FOR, LET, and RETURN.

Summary:

1. XPath is still in its nascent stage of development and as such is still a component of a query language.

2. XQuery supports XPath and extended relational models.

3. XQuery is a read-only language that is not very easy to formulate.

4. XQuery is not a standard and is difficult to optimize leading to poor performance.

BPEL

BPEL is a Web Service Sequencing Language. A BPEL Process defines a conversation flow chart and a BPEL Process instance is a particular conversation following the chart which consists of only WSDL-described message exchanges.

What are partnerLink Types

partnerLink:

Links to all the different WSDL-defined web services that a BPEL process instance interacts with are called partner links. They are concrete references to services that a BPEL business process interacts with.

• Links to WSDL-defined web services that are invoked by a BPEL process are called Invoked partner links.
• Similarly, links to WSDL-defined web services that can invoke a BPEL process are called Client partner links.

Each BPEL process will definitely have at least one Client partner link since a BPEL process can only be instantiated with a call from a Client partner.

SOA : Fault Handling Framework

Today I will show you one of the most important concept in any software developed using any programming language i.e "Faults Handling Framework ".Like in every other language there are number of mechanisms to handle exceptions that may arise while invoking certain piece of code. In BPEL as well there is a mechanism for handling faults.These faults should be handled and required actions should be taken in event of failure at any stage.There are two categories of BPEL faults:

• Business Faults
• Runtime Faults

Business faults are application-specific faults that are generated when there is a problem with the information being processed (for example, when a social security number is not found in the database). A business fault occurs when an application executes a throw activity or when an invoke activity receives a fault as a response. The fault name of a business fault is specified by the BPEL process service component.A business fault can be caught with a faultHandler using the faultName and a faultVariable.

<catch faultName="ns2:BusinessFault" faultVariable="BusinessFaultVar">

Runtime faults are the result of problems within the running of the BPEL process service component or web service (for example, data cannot be copied properly because the variable name is incorrect). These faults are not user-defined, and are thrown by the system. They are generated if the process tries to use a value incorrectly, a logic error occurs (such as an endless loop), a Simple Object Access Protocol (SOAP) fault occurs in a SOAP call, an exception is thrown by the server, and so on.

Several runtime faults are automatically provided. These faults are included in the http://schemas.oracle.com/bpel/extension namespace. These faults are associated with the messageType RuntimeFaultMessage. The WSDL file shown below defines the messageType:

<?xml version="1.0" encoding="UTF-8" ?>
<definitions name="RuntimeFault"
  targetNamespace="http://schemas.oracle.com/bpel/extension"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://schemas.xmlsoap.org/wsdl/">

  <message name="RuntimeFaultMessage">
   <part name="code" type="xsd:string" />
   <part name="summary" type="xsd:string" />
   <part name="detail" type="xsd:string" />
  </message>
</definitions>

If a faultVariable (of messageType RuntimeFaultMessage) is used when catching the fault, the fault code can be queried from the faultVariable, along with the fault summary and detail.

bindingFault
A bindingFault is thrown inside an activity if the preparation of the invocation fails. For example, the WSDL of the process fails to load. A bindingFault is not retryable. This type of fault usually must be fixed by human intervention.

remoteFault

A remoteFault is also thrown inside an activity. It is thrown because the invocation fails. For example, a SOAP fault is returned by the remote service.

replayFault

A replayFault replays the activity inside a scope. At any point inside a scope, this fault is migrated up to the scope. The server then re-executes the scope from the beginning.

In this example I'll demonstrate how to handle different types of BPEL faults inside any BPEL process and take required actions.BPEL process will be created based on a schema and it will be exposed as web service.To showcase diferent types of faults we will be using primarily two activities such as Throw and Catch.

Throw Activity is used to generates a fault from inside the business process.
Catch Activity is used to catch specific faults individually such as business,runtime or binding fault.Catch All activity catches all the faults that are not being catch in other catch activities.


                                                                                                                 pavankumar

SOA MDS Repository

    Updating single files in the MDS Repository

SCA composites contain several metadata artefacts such as xsds ,wsdls, xslts and dvm files that should be stored in the Oracle metadata repository MDS. In order to do this, it is very common to generate a separate project for these artefacts and deploy it as a whole using JDeveloper directly or the ant commands. For time to time the question arises on how to update single files that are stored inside the repository without having to deploy the whole project.

Disclaimer

Only metadata files under the “apps” directory should be updated using the following procedure. Deployed composite files under the “deployed-composites” or “soa” directories should not be changed manually because it could damage the running instances and the correspondent deployments. In the worst cases, the domain can become unstable and unusable. Also, Oracle doesn’t support it.

Oracle provides a useful command called “importMetadata” that can be use to update one or more files. Lets take the following repository as an example

In order to update a single file, lets say HRManagementService.wsdl, several task have to be executed

1.   Preparing the local environment

Updating the MDS is done using a WLST command. Therefore there has to be a JDeveloper  or a Weblogic installation in the local environment.

The same MDS path structure has to be created in the local system in order to update a specific file in the repository. In the sample MDS repository, this file is located under /apps/mdsstuff/wsdl. This means that this path has to exist somewhere in the local system (for example under ‘/Users/testuser/Documents/work/ mdsdemo/apps/ mdsstuff / wsdl’) and the new version of HRManagementService.wsdl has to be inside the wsdl folder.

2.   Packaging the files (only for remote updating)

Here is where things get trickier. The WLST command will work perfectly if it is executed where the Admin server is running. Single files can be referenced and uploaded to the MDS repository. When executed remotely (not where the Admin server is running), the file(s) that are going to be updated have to be packed in an archive file like a zip or a jar.

In a linux/unix system, this archive can be generated with the use of the “zip” command:

zip -r /tmp/MyDemos/mdsdemo/mds.jar apps -i *. wsdl

where:

• /tmp/MyDemos/mdsdemo/can be any path. It is where the zip/jar archive is going to be created.
• mds.jar is the name of the archive file.
• apps is the apps directory where the files reside. For the previous example, the command zip has to be executed from the following directory ‘/Users/testuser/Documents/work/ mdsdemo’.
• *.wsdl defines that  only files ending with .wsld are to be included in the archive.

In windows other utilities can be used such as winzip, 7zip and winrar. It is important to mention that the generated archive should only contain the files that are going to be update to the repository. All other files, including the hidden ones from SVN, CVS, DS_STORE or backup files, should not be added to the archive.

3.   Starting WLST and connecting to then target environment

Open a console and navigate to the following folder:  <MIDDLEWARE_HOME>/oracle_common/common/bin where MIDDLEWARE_HOME is the path in the local system where the Oracle Middleware products are installed (in Windows the default location is usually the following: C:\Oracle\Middleware)

In there execute the wlst application: wlst.cmd (or wlst.sh)

$ ./wlst.sh

Now connect to the admin server

wls:/offline> connect(‘user’,’password’,’t3://host:port’)

where:

• user: assigned user with logging and deployment privileges or weblogic.
• password:  the password of the user
• host: host where the admin server is running.
• port: listening port of the admin server

4.   Uploading the file

After having completed the steps above, the file(s) can be uploaded to the MDS. Here again, there is a difference between the local and the remote update. For local update use the following command:

importMetadata(application=’soa-infra’, server=’managedserver’, fromLocation=’path_to_file’, docs=’mds_files_to_update’);

where:

• managedserver: name of the managed server  where the soa suite  is running.
• path_to_file: path pointing to the location of the apps folder. For the previous sample it will be like this:  /Users/testuser/Documents/work/ mdsdemo.
• mds_files_to_update: the mds path and name of the file that is going to be updated. For the example provided, the path looks like this: /apps/ mdsstuff / wsdl/ HRManagementService.wsdl

The command for the remote update is slightly different:

importMetadata(application=’soa-infra’, server=’managedserver’, fromLocation=’path_to_archivefile’, docs=’mds_files_to_update’, remote=’true’);

• managedserver: name of the managed server  where the soa suite  is running.
• path_to_file: path pointing to the direction of the archive file. The name of the file has to be also included. Sample: /tmp/MyDemos/mdsdemo/mds.jar.
• mds_files_to_update: the mds path and name of the file that is going to be updated. Following the example of above, the path looks like this: /apps/ mdsstuff / wsdl/ HRManagementService.wsdl
• remote: indicates that this is a remote update and should be set to true.

This command uploads the file and updates the MDS repository.