NXSD Tester :- Test your files against NXSD neither deploying the SOA code nor JDeveloper(Command line tool)

Hello Folks,

Here is the exciting command line tool to test the FTP/File adapter NXSD to test the files.

In any middleware tool,

 If you want to test your nXSD(Native schema ) wrt files, you have only two options.

      1. Deploy the code to Server and put the Input testing files to file pickup location and run the code.

            2. Use JDeveloper to test the file wrt the nXSD.

Here I found another option to test the files against nXSD(Native schema). (Source: Oracle).

I have used the some libraries to test the NXSD. Here you see all the mandatory JAR to be used in below tool.

List of JARs.
      1. bpm-infra.jar
      2. mail.jar
      3. test-translator.jar
      4. translator.jar
      5. xml.jar
      6. xmlparserv2.jar

You can find all the JARs in weblogic folder post instillation.

Step by Step procedure:

Prerequisites:

     1. Have the java installed.

      2. Set the list of jars added to the class path.

      3. Run  java xlator.util.Translate –help to check the dependency . You should be able to run the command.

Procedure:

    1. Add the mandatory JAR files to one folder.

    2. Place the NXSD and Input file on the same folder to test.

    3. Open CMD in that folder path.

    4.  Run the below commands to test the files. (Note: You need to set the classpath before run these commands otherwise you will not be able to run)

Command 1: java xlator.util.Translate -inbound -schema (NXSD_Schema.xsd) -root (Root-Element Name) -input (InputFile.txt) -output (FileName.xml) 

You will get the tested output XML file if the Input files follow the schema.

Command 2: Run this command to test the file with de-batching as series of output files.

java xlator.util.Translate -inbound -debatch 1 -schema (NXSD_Schema.xsd) -root (Root-Element Name) -input address-csv.txt -output (FileName.xml)

You will get the series of tested output XML files if the Input files follow the schema & if you have the multiple records in the Input file.

Happy learning….!!!!!!!! Fun Sharing….!!!!!!!!!!!!!!!

Ram.

Undeploy Composite Manually from Oracle SOA Suite EM

Hi Folks,

If you find any difficulty while deploying / undeploying / redeploying and your EM is not supporting to do the specific tasks you just need to undeploy the composites manually.

This is due to many reasons not only composite not deployed properly / DB reference issue/ MDS issue.

Step 1: Log on to EM right click on SOA_INFRA --> Adminstration-->MDS configuration.
Step 2: Export metada.
Step 3: soa_infra_metadata.zip file will be downloaded. Unzip the folder you will find the folder called deployed-composites and under this deployed-composites.xml.
Step 4: Open the .xml file and remove the entry of which composite / partition is having issue.

ZIP it again and import the MDS from EM.

You just need to restart the server then you can see the particular partition / composite would be undeployed.

If you still find any difficulty in deploying the same composite then you need to remove the entry in MDS as well . To delete the entry in MDS you follow my previous post. Click Here

Happy Learning...!!!!!!!!!!!! Fun Sharing.........!!!!!!!!!

Meanings of the BPEL Standard Faults - Oracle SOA Suite 11g

Hi Folks.


Here are some so called 'BPEL Standard Faults' listed but without detailed information.
Oracle SOA SUite -Version 11.1.1.1.0 and later.

Fault name Description ambiguousReceive Thrown when a business process instance simultaneously enables two or more IMAs for the same partnerLink, portType, operation but different correlationSets, and the correlations of multiple of these activities match an incoming request message. completionConditionFailure Thrown if upon completion of a directly enclosed <scope> activity within <forEach> activity it can be determined that the completion condition can never be true. conflictingReceive Thrown when more than one inbound message activity is enabled simultaneously for the same partner link, port type, operation and correlation set(s). conflictingRequest Thrown when more than one inbound message activity is open for the same partner link, operation and message exchange. correlationViolation Thrown when the contents of the messages that are processed in an <invoke>, <receive>, <reply>, <onMessage>, or <onEvent> do not match specified correlation information. invalidBranchCondition Thrown if the integer value used in the <branches> completion condition of <forEach> is larger than the number of directly enclosed <scope> activities. invalidExpressionValue Thrown when an expression used within a WS-BPEL construct (except <assign>) returns an invalid value with respect to the expected XML Schema type. invalidVariables Thrown when an XML Schema validation (implicit or explicit) of a variable value fails. joinFailure Thrown when the join condition of an activity evaluates to false and the value of the suppressJoinFailure attribute is yes. mismatchedAssignmentFailure Thrown when incompatible types or incompatible XML infoset structure are encountered in an <assign> activity. missingReply Thrown when an inbound message activity has been executed, and the process instance or scope instance reaches the end of its execution without a corresponding <reply> activity having been executed. missingRequest Thrown when a <reply> activity cannot be associated with an open inbound message activity by matching the partner link, operation and message exchange tuple. scopeInitializationFailure Thrown if there is any problem creating any of the objects defined as part of scope initialization. This fault is always caught by the parent scope of the faulted scope. selectionFailure Thrown when a selection operation performed either in a function such as bpel:getVariableProperty, or in an assignment, encounters an error. subLanguageExecutionFault Thrown when the execution of an expression results in an unhandled fault in an expression language or query language. uninitializedPartnerRole Thrown when an <invoke> or <assign> activity references a partner link whose partnerRole endpoint reference is not initialized. uninitializedVariable Thrown when there is an attempt to access the value of an uninitialized variable or in the case of a message type variable one of its uninitialized parts. unsupportedReference Thrown when a WS-BPEL implementation fails to interpret the combination of the reference-scheme attribute and the content element OR just the content element alone. xsltInvalidSource Thrown when the transformation source provided in a bpel:doXslTransform function call was not legal (i.e., not an EII). xsltStylesheetNotFound Thrown when the named style sheet in a bpel:doXslTransform function call was not found.

Happy Learning...!!!!!!!!!!!! Fun Sharing.........!!!!!!!!!

Manual Recovery Mechanisms in Oracle SOA Suite 11g – BPEL Process Manager

Hi Folks,

 My intention of this post is to provide a quick reference for Manual Recovery of Faults within the SOA.

 It aims to present some of the valuable information regarding Manual recovery in one place.

Introduction:

Integration flows can fail at run-time with a variety of errors. The cause of these failures could be either Business errors or System errors.  When Synchronous Integration Flows fail, they are restarted from the beginning. On the other hand, Asynchronous Integration flows when they error can potentially be resubmitted/recovered from designated/pre-configured milestones within the flow. These milestones could be persistence points like queues topics or database tables, where the state of the flow was last persisted. Recovery is a mechanism whereby a faulted Asynchronous Flow can be rerun from such a persistence milestone

BPEL Message Recovery:

To understand the BPEL Message Recovery, let us briefly look into how BPEL Service engine performs asynchronous processing. Asynchronous BPEL processes use an intermediate Delivery Store in the SOA Infrastructure Database to store the incoming request. The message is then picked up and further BPEL 

processing happens in an Invoke Thread. The Invoke Thread is one among the free threads from the ‘Invoke Thread Pool’ configured for BPEL Service Engine. The processing of the message from the delivery Store onwards until the next dehydration in the BPEL process or the next commit point in the flow constitutes a transaction. Figure below shows at a high level the Asynchronous request handling by BPEL Invoke Thread. Any unhandled errors during this processing will cause the message to roll back to the delivery Store.

During Recovery of these messages, the end user cannot make any modifications to the original payload. The messages marked recoverable can either be recovered or aborted. In the former case, the original message is simply redelivered for processing again.

The BPEL Configuration property ‘MaxRecoverAttempt’ determines the number of times a message can be recovered manually or automatically. Messages go to the exhausted state after reaching the MaxRecoverAttempt. They can be selected and ‘Reset’ back to make them available for manual/automatic recovery again.

A Fault Policy with configurable Actions to be bound to SOA Component. These can be attached at the Composite, Component or Reference levels. The configured Actions will be executed when the invocation fails. The available Actions could be retry, abort, human intervention, custom java callout, etc. When the Action applied is human intervention the faults become available for Manual Recovery from the Oracle Enterprise Manager Fusion Middleware Control [EM FMWC Console]. They show up as recoverable instances in the faults tab of ‘SOA->faults and rejected messages’

Automatic recovery program for pending BPEL call back messages:

BPEL engine maintains all async call back messages into database table called dlv_message. You can see such all messages in BPEL console call-back manual recovery area.The query being used by bpel console is joined on dlv_message and work_item tables.This query simply picks up all call back messages which are undelivered and have not been modified with in certain threshold time.

Call-back messages are processed in following steps

· BPEL engine assigns the call-back message to delivery service

· Delivery service saves the message into dlv_message table with state 'UNDELIVERED-0'

· Delivery service schedules a dispatcher thread to process message asynchronously

· Dispatcher thread enqueues message into JMS queue

· Message is picked up by MDB

·  MDB delivers the message to actual BPEL process  waiting for call-back and changes state to 'HANDLED=2'

So given above steps, there is always possibility that message is available in dlv_message table but MDB is 

failed in delivering it to BPEL process which keeps message always in state= 0.

Recovering the instances from recovery:

The instances in the recovery queue can be recovered manually to continue the processing.

Below are the some of the reasons the instances to go to manual recovery.

1.There are not enough threads or memory to process the message.

2.The server shuts down or crash before it finishes processing the BPEL message

3.The engine could not finish processing the message before reaching the time-out as dictated by the 

transaction-timeout configuration

BPEL process manager has a nice UI for looking at and managing these, but what if we need to be alerted

 when a process goes into one of these states? Well, BPEL PM doesn't have that capability if we want 

we can write a custom code for that or else we manually go and reinitiate the recoverable instances in EM.

Recovering the BPEL instances:-

1. Login  to EM console

2. Right click on soa-infra  ,Click on Service Engine --> BPEL

3. Click on Recovery tab

4. Change the Type accordingly(Invoke,Activity,Callback) and the Message state to “Undelivered”  

and click on search

5. All the recoverable messages that match the criteria will be displayed.

6. Select the required messages and click on Recovery button.

Auto Recovery feature in BPEL

Configuration:

Auto Recovery’ configuration is done by setting few of the MBean properties in EM console. 

To configure it in EM console one should navigate to soa-infra -> SOA Administration ->

 BPEL Properties -> More BPEL Configuration Properties -> RecoveryConfig.

This will bring up the following screen showing the default parameters. BPEL Auto recovery is enabled

 by default.The properties startWindowTime and stopWindowTime specify the period during 

which Auto Recovery is active. By default auto recovery feature will be active from 12AM to 4AM everyday (remember that it’s SOA server time), shown in above screenshot. We can change these settings by simply updating the time values in 24 hr format and do click on Apply.

The property maxMessageRaiseSize specifies the number of messages to be sent in each recovery attempt, in effect resembles the batch size.

The property subsequentTriggerDelay specifies interval between consecutive auto recovery attempts and the value is 300 sec by default.

The property threshHoldTimeInMinutes is used by BPEL engine, to mark particular instance eligible for auto recovery once the recoverable fault occurs which is 10 min by default.

If we observe closely, none of these properties mention about number of recovery attempts to be made which is altogether a separate MBean property. To set, navigate to soa-infra -> SOA Administration -> BPEL Properties -> More BPEL Configuration Properties -> MaxRecoverAttempt. The default value is 2.

To disable ‘Auto Recovery’, set the maxMessageRaiseSize property value to 0 as shown above.

Auto Recovery Behavior:

Whenever a recoverable fault (this term is more abstract, I verified this behavior with Remote, Binding and User Defined Faults) occurs during the BPEL processing, it will be visible in Recovery console. If Auto Recovery is enabled, after threshHoldTimeInMinutes BPEL runtime will try to auto recover the instance. If it’s not successful, again number of recovery attempts will be made as given for MaxRecoverAttempt with an 

interval as given forsubsequentTriggerDelay. If instance fails even after these maximum recover attempts,

 the instance will be marked as exhausted (can be queried on recovery console using message state as 

exhausted). We can use ‘Reset’ button to make these instances eligible for Auto Recovery again.

Note that, we observe this behavior only when the fault is thrown back to BPEL runtime or fault is not caught within BPEL process.

SOA 11.1.1.6 New Features for BPEL Message Recovery

SOA 11.1.1.6 added an important feature to the Message Recovery subject.

SOA 11.1.1.6 added more pro-active alerts for BPEL stuck messages. A small part of this feature was available since SOA 11.1.1.5 but just for the Composite Flow Trace, so you had to know the flow trace where you could have problems. Now clicking the soa-infra inside EM, we see a global alert that there are messages needing recovery:

Also, we have the same alert when clicking a composite which has some of these messages pending recovery while it disappears when we move to a composite which does not have such messages.

By clicking Show Details, we can see how many messages are pending recovery, grouped by type:

And clicking Go to BPEL Recovery Console will redirect you to the BPEL recovery console where you can recover or cancel the message:

Well, that’s it. This new feature is simple yet very powerful, helping SOA administrators to get alerts when messages need recovery and be more pro-active when administering the SOA environment.

Happy Learning...!!!!!!!!!!!! Fun Sharing.........!!!!!!!!!