SOA 11g- Message Selector Property in JMS Adapter

In my previous post, I explained how to set custom JMS header property. In this post I will show you how to set Message Selector property in JMS adapter to filter the incoming message based on custom JMS header property.

We use Message Selector property when your messaging application needs to filter the messages it receives.

This field is also optional. It filters messages based on header and property information. The message selector rule is a Boolean expression. If the expression is true, then the message is consumed. If the expression is false, then the message is rejected.

For example, you can enter logic, such as:

·         city in (‘Mohali’, 'Mumbai', 'Delhi')

·         city=’Mohali’

To set the Message selector property, open JMS adapter configuration Wizard. Here you can set Message selector property as shown in below diagram.

Message Selector Property

If you set Message selector property as shown in above figure then JMS adapter will process only those message which will contains custom JMS header property “city” having value “Mohali”.

SOA 11g- Set Custom JMS Header properties In Mediator & BPEL

In this post, I will show you how you can set custom JMS header properties in Mediator and BPEL components.

By Default a JMS message includes a number of header fields that contain information used to identify and route messages. The supported headers for an incoming message are:

Ø   JMSCorrelationID

Ø   JMSDeliveryMode

Ø   JMSExpiration

Ø   JMSMessageID

Ø   JMSPriority

Ø   JMSRedelivered

Ø   JMSTimestamp

Ø   JMSType

But we can also set Custom properties.

Mediator: To set custom JMS header property in Mediator follows below steps.

Ø  Open .mplan file and click on assign activity. Here we are defining new custom header property (city).

Ø  To set city custom header property choose “jca.jms.JMSProperty” and append “.city” to it. You can assign any expression or hard-code this property value.

  

BPEL: To set custom JMS header property in BPEL follows below steps.

·         Go to *.bpel file, check the invoke code and add a new property called jca.jms.JMSProperty.city, for instance:

<invoke name="Invoke1" inputVariable="Invoke1_Produce_Message_InputVariable"

            partnerLink="Produce_Message" portType="ns1:Produce_Message_ptt"

            operation="Produce_Message" bpelx:invokeAsDetail="no">

              <bpelx:inputProperty name="jca.jms.JMSProperty.city" variable="cityVar"/>

 </invoke>

  

Currently this property is equal to cityVar but you can also use expression to assign value to city property.

              <bpelx:inputProperty name="jca.jms.JMSProperty.city" expression="2"/>

Remember you will not find this property in header tab, you need to manually set this property in *.bpel file for specific invoke.

When you will run the composite, you will see custom JMS header property at admin console for that queue.

Oracle SOA Interview Questions and Answers (OWSM) Part- 7

This is Chapter-7 of Oracle SOA interview questions and answers series.


Question: What is OWSM?

 Answer:  OWSM stands for Oracle Web Service Manager. Oracle Web Services Manager offers a comprehensive and easy-to-use solution for policy management and security of service infrastructure. It is a standalone platform for securing and managing access to web services.

Question:  How do we call secured web service from SOA?

Answer: By using OWSM policies.

Question: Can we generate custom OWSM policies?

Answer: Yes, we can create custom OWSM policies.

Question:  By how many ways we can add OWSM policy to Web Service?

Answer:

·         Through policy annotations at design time

·         Via the Administration Console at runtime

·         Via Fusion Middleware Control or WLST

Question: When we call secured web service from SOA, which policy we will use “Client” or “Service”?

Answer: When we call secured web service from SOA then we add “Client” policy to reference partner link and when we want to secure our web service then we use “Service” policy.

Question: Can we use OWSM with Oracle Service Bus?

Answer: Yes, we can access OWSM policies from OSB.

Question: Can we attach OWSM policy to multiple composites to secure composites?

Answer: yes, we can apply one policy to all composites in one domain using policy sets.

Question: what is the scope of Policy Sets or where we can apply Policy sets ?

Answer:

·         Domain — all policy subjects of the specified type in a domain

·         Application or Partition—all policy subjects of the specified type in an application or SOA partition

·         Application module or SOA composite—all policy subjects of the specified type in an application module or SOA composite

·         Service or reference—all policy subjects of the specified type in a SOA service or reference

·         Port or component—all policy subjects of the specified type in a port or SOA component

Click here to go to Chapter-6                                                            Click here to go to Chapter-8

Oracle SOA Interview Questions and Answers (Error Handling) Part- 6

This is Chapter-6 of Oracle SOA interview questions and answers series.


Question: By how many ways we can handle error/fault in BPEL?

Answer: By using Catch blocks & Fault handling framework.


Question: Can we use both Catch block & fault handling framework in one BPEL?

Answer: Yes, we can have both Catch Block & Fault policies files in one BPEL.


Question: Standard Faults in BPEL?

Answer: Below is the list of Standard Faults in BPEL.

·         bindingFault, conflictingReceive, conflictingRequest, correlationViolation

·         forcedTermination, invalidReply, joinFailure, mismatchedAssignmentFailure

·         remoteFault,  repeatedCompensation, selectionFailure,  uninitializedVariable

Question: Standard Faults in Mediator?

Answer: Mediator has only one standard fault.

{http://schemas.oracle.com/mediator/faults}mediatorFault.


Question: How to get Fault Trace in CatchAll block?

Answer: By using getFaultAsString() function.


Question: Can we have custom faults in BPEL?

Answer: Yes we can create custom faults in BPEL, these faults are usually called Business Faults and we usually handle it by using specific Catch block.


 Question: Can we re throw a fault from Catch blocks?

Answer: Yes, we can re-throw fault from Catch block.


Question: Where we keep fault-policies.xml & fault-binding.xml files?

Answer: We can keep these files either local to project or in MDS and in both the cases we have to specify the path in composite.xml file.

Click here to see more Interview question and answer.


Click here to go to Chapter-5                                                      Click here to go to Chapter-7

Oracle SOA Interview Questions and Answers (MDS) Part- 5

TThis is Chapter-5 of Oracle SOA interview questions and answers series.


Question: What is MDS & Why we use MDS in Oracle SOA?

Answer: MDS stands for Oracle MetaData Service. It is central repository inside Oracle Fusion Middleware. MDS purpose is to provide centralized store where we can keep, manage & access metadata.

Metadata is often defined as data about data, or in other words, pieces of information that describes and gives meaning to other information. Typical examples of metadata used by Oracle Fusion Middleware components are XML files, XSD schema files, XSL transformations, SCA composites, BPEL processes, WSDLs, business rules, Oracle ADF pages, JaveServer Pages (JSP), and Oracle ADF task flows, among others.

The same metadata that is used during the design phase of application is used at application runtime through the metadata service layer. This ensures consistency through the lifecycle of the application. Metadata such as XML files or XSD schema files is usually shared among different components. Therefore, it is not only necessary that those resources can be accessed easily and referenced by all the components, but it is also important that they remain consistent; a change in the metadata should be reflected in all the components that are referencing it. Having only one copy of each metadata resource avoids unnecessary redundancy and guarantees that the changes are made in only one place.

Question: Types of MDS Repository?

Answer: File-Based & DB Based.

Question: What is File-Based MDS Repository?

Answer:  The idea behind file-based repositories is to allow developers to have a light repository available in their local environment that can be easily adapted for development and tests; a file-based repository relieves developers of having to configure and maintain an external database while providing necessary functionality, such as file referencing and customizations. These kinds of repositories are easily modified and maintained, since they define a directory structure similar to any other directory structure inside an operating system. They can be navigated and altered using common shell commands or any kind of visual file explorer application. The file-based repository is usually located inside the Oracle JDeveloper home (JDEV_HOME/integration) if the default configuration is used.

Question: What is DB-Based MDS Repository?

Answer:  Database-based repositories are used in production environments where robustness is needed. These repositories are created using the Repository Creation Utility (RCU) application from Oracle. This utility helps with the creation of a new database schema with its corresponding tables and objects. Repositories can later be registered or deregistered via the Oracle Enterprise Manager Fusion Middleware Control console.

Question: Which configuration file store MDS configurations?

Answer: The adf-config.xml file is a configuration file that is used to store MDS Configurations.

Question: What type of WSDL file we usually keep in MDS?

Answer: We usually keep Abstract WSDL’s only in MDS.


Click here to go to Chapter-4                                                                  Click here to go to Chapter-6