JMS Topic Queue high avaibalily using durable and persistance feauture in Oracle SOA OSB

JMS Topic Queue high avaibalily using durable and persistance feauture in Oracle SOA OSB

JMS is used for improving the performance of the overall system and reliability of the system.

JMS Queue:
FIFO - First Msg will be Fetched First from Queue

Two import aspect of JMS Queu are

1. What will happen to the jms message when JMS server is down?
2. What will happen when the client which need to receive the message is down?

If we make the message as persistance then both above problem will be solved ie., msg will be persisten in the DB hence msg will be always be avaiable till its consumed by the client.

Persistance of the msg in the queue can be achieved by enabling the "Enable Message Persistance" of business service under JMS TRansport Tab. Screenshot is shown below





JMS Topic -
Producer and N number of subscriber is the concept of JMS Topic.

Oracle SOA Reading the message from Topic:

We can make the message persisted in the DB by persisting  the msg in the topic. Persistance can be achieved by enabling the "Enable Message Persistence" of business service under JMS TRansport Tab. Screenshot is shown below

Oracle SOA Reading the message from Topic:
Consider there are two subscriber for a topic. If one subscriber read the message and another subscript server is down then it will not be receiving the message any more! But this behaviour can be avoided by means using the Durable subscriber. Ie., message will be present in the topic till durable subscriber consumed that message. To make the subscriber durable  we need to enable the durable checkbox in proxsy service. Screenshot is given below.

Oracle SOA BPEL Correlation Why When How?

I like the about correlation from swapnil blog
http://swapnil-soa.blogspot.co.uk/2008/01/correlation-this-post-would-effort-to.html

Below one has few changes for clarity.

This post would effort to explore the meaning and need of correlating requests and the best way to do them using Oracle SOA Suite.

What & Why
In common business scenarios it is not possible to have a synchronous response to each of our requests. Mostly the business has to deal with vendors, who would need to undergo a detailed process to come up with a solution. However, this response may not be necessarily binding business from carrying on its other activities. In such scenarios, the business enters in to asynchronous communication with these third parties. The async process necessarily stresses that the response may come back at a later time, through callback or polling mechanism as is suitable.

In case of a single instance its quite easy to match the response to request, however, when there are multiple instances the business would be wondering which request has been responded to. For example, if a travel booking agent spawns 10 requests for Frankfurt to Paris, and after a while airline responds to one of those 10 requests, it would not be safe to assume that this is a response to first request only. Hence the travel agent would tag in an ID to segregate one request for another, and would expect the airline to return this id unaltered to match the request. This id, which enables requestor to correlate the response sent by the provider, is called Correlation Id.

How (in Oracle BPEL)
Oracle BPEL provides us with two mechanisms through which an asynchronous callback message could map to its calling instance in the crowd.

• WS-Addressing
• Correlation Sets

WS-Addressing
“How does the callback maps to the correct instance out of so many waiting processes”, it’s a very common surprise to all beginners, creating first ever Asynchronous Invoke in BPEL Process Manager. The answer is, any time an asynchronous service is invoked, Oracle BPM, instills a message UID in WS-Addressing headers that float with SOAP Packets, which are used internally by the BPEL Server to correlate the flowing request/response.

This is the default mechanism supported by Oracle BPEL Process Manager, which is overridden automatically when the user opts to create his own correlation set.

Correlation Sets
Correlation Sets enable you to correlate asynchronous messages based on message body contents.

Why?

The question now arises, why ever would a BPEL developer like to over-ride default WS-Addressing correlation and use content-based correlation. Well, he won’t have to; if the called service is an Oracle BPEL, or the one, which supports and retains WS-Addressing headers sent, and returns the same in response.

The reasons, to use content-based correlation, could be many; some of the familiar ones that come to my mind are –

1. The asynchronous web service invoked by BPEL does not support/understand WS-Addressing headers.
2. When BPEL instance is expecting messages from a third party, for example, a file-poller.
3. When asynchronous call has multiple hops and reply is received directly from end system. For example, Request path is A > B > C > D and response comes to A directly from D, i.e. D > A.

How?

WE now understand and appreciate, need of correlation and the two mechanisms to achieve correlation. In WS-Addressing, we, as in developer, does not bother of how the correlation ID is created and maintained. However, in content-based correlation the responsibility of managing correlation set, defining property alias and initializing the correlation with appropriate value falls on developer.

To understand how to perform these tasks, we would start by understanding in which activities do we need correlation. The Correlation is required whenever data is going out or coming in to the BPEL process, hence Correlation works only with Invoke, Receive, Pick and Reply activities.

To create a correlation of our own, we need to create the Correlation Set first. A correlation set is a set of properties shared by all messages in the correlated group.

The correlation set is normally instantiated on invoke or receive activity. When correlation is instantiated on receive activity it is fairly straight forward, you create a correlation set, and select initiate = “yes”.

However, when you have to create correlation set on invoke, we have one addition option to understand, it’s the “pattern”. Now before we move ahead with “pattern”, lets explore what is “initiate” option.

• in - specifies that the correlation applies to inbound messages
• out - specifies that the correlation applies to outbound messages
• out-in - specifies that the correlation applies to both inbound and outbound messages

When initiate = “yes”,
Pattern=”in” means the correlation is being instantiated with a value that is coming into the BPEL, from another service. Clearly, this invoke is then not the one which is invoking an asynchronous process, as the pattern suggests a response coming back.
Pattern = “out” means the correlation is being instantiated on the message that is going out of our BPEL.
Pattern = “out-in” means the correlation would be set on a variable that is part of both outgoing and incoming parameter, in this synchronous invoke. However, its nature is very much questionable.

When initiate=”no”
The above patterns would reflect which way the variable needs to be validated, inward, outward or both ways.

Creating a Correlation Set 

Correlation sets uses correlation tokens available inside messages, headers or business documents. Correlation tokens are the declarative properties of messages. A property is an element within a message identified by a query. Property aliases are the constructs to specify the queries to identify properties.

To create Correlation Set click the Createicon, and insert the appropriate values. As shown in the diagram below:



Here you would also need to create a Property (not shown in diagram above, its just beneath Xpath text box. This way we declared one of the property alias for instantiation, we need to create another one for validation.

Select the BPEL in diagram, in the adjacent Structure window, you would see set of properties. Right Click Property Alias, and select “Create Property Alias…”.



Now, select the appropriate message part, and then enter Xpath query string in the text box. You can use Ctrl+Space for Autofill.




Now, select the appropriate message part, and then enter Xpath query string in the text box. You can use Ctrl+Space for Autofill

Oracle SOA BPEL Design Patterns

Referred from Oracle docs:

6.1 Introduction to One-Way Messages

In a one-way message, or fire and forget, the client sends a message to the service (d1 in Figure 6-1), and the service does not need to reply. The client sending the message does not wait for a response, but continues executing immediately. Example 6-1 shows the portType and operation part of the BPEL process WSDL file for this environment.

Example 6-1 One-Way WSDL File

. . .
<wsdl:portType name="BPELProcess1">
      <wsdl:operation name="process">
         <wsdl:input  message="client:BPELProcess1RequestMessage" />
      </wsdl:operation>
</wsdl:portType>
. . .

Figure 6-1 provides an overview.

Figure 6-1 One-Way Message

Description of "Figure 6-1 One-Way Message"

BPEL Process Service Component as the Client

As the client, the BPEL process service component needs a valid partner link and an invoke activity with the target service and the message. As with all partner activities, the Web Services Description Language (WSDL) file defines the interaction.

BPEL Process Service Component as the Service

To accept a message from the client, the BPEL process service component needs a receive activity.

6.2 Introduction to Synchronous Interactions

In a synchronous interaction, a client sends a request to a service (d1 in Figure 6-2), and receives an immediate reply (d2 in Figure 6-2). A BPEL process service component can be at either end of this interaction, and must be coded based on its role as either the client or the service. For example, a user requests a subscription to an online newspaper and immediately receives email confirmation that their request has been accepted. Example 6-2 shows theportType and operation part of the BPEL process WSDL file for this environment.

Example 6-2 Synchronous WSDL File

. . .
<wsdl:portType name="BPELProcess1">
      <wsdl:operation name="process">
         <wsdl:input  message="client:BPELProcess1RequestMessage" />
         <wsdl:output message="client:BPELProcess1ResponseMessage"/>
      </wsdl:operation>
</wsdl:portType>

Figure 6-2 provides an overview.

Figure 6-2 Synchronous Interaction

Description of "Figure 6-2 Synchronous Interaction"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of a synchronous transaction, it needs an invoke activity. The port on the client side both sends the request and receives the reply. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

When the BPEL process service component is on the service side of a synchronous transaction, it needs a receive activity to accept the incoming request, and a reply activity to return either the requested information or an error message (a fault; f1 in Figure 6-2) defined in the WSDL.
For more information about synchronous interactions, see Chapter 8, "Invoking a Synchronous Web Service from a BPEL Process."

6.3 Introduction to Asynchronous Interactions

In an asynchronous interaction, a client sends a request to a service and waits until the service replies. Example 6-3 shows the portType and operation part of the BPEL process WSDL file for this environment.

Example 6-3 Asynchronous WSDL File

. . .
<wsdl:portType name="BPELProcess1">
      <wsdl:operation name="process">
         <wsdl:input message="client:BPELProcess1RequestMessage"/>
      </wsdl:operation>
</wsdl:portType>

. . .
<wsdl:portType name="BPELProcess1Callback">
      <wsdl:operation name="processResponse">
         <wsdl:input message="client:BPELProcess1ResponseMessage"/>
      </wsdl:operation>
</wsdl:portType>

Figure 6-3 provides an overview.

Figure 6-3 Asynchronous Interaction

Description of "Figure 6-3 Asynchronous Interaction"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of an asynchronous transaction, it needs an invoke activity to send the request and a receive activity to receive the reply. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

As with a synchronous transaction, when the BPEL process service component is on the service side of an asynchronous transaction, it needs a receive activity to accept the incoming request and an invoke activity to return either the requested information or a fault. Note the difference between this and responding from a synchronous BPEL process: a synchronous BPEL process uses a reply activity to respond to the client and an asynchronous service uses an invoke activity.
For more information about asynchronous interactions, see Chapter 9, "Invoking an Asynchronous Web Service from a BPEL Process."

6.4 Introduction to Asynchronous Interactions with a Timeout

In an asynchronous interaction with a timeout (which you perform in BPEL with a pick activity), a client sends a request to a service and waits until it receives a reply, or until a certain time limit is reached, whichever comes first. For example, a client requests a loan offer. If the client does not receive a loan offer reply within a specified amount of time, the request is canceled. Figure 6-4 provides an overview.

Figure 6-4 Asynchronous Interaction with Timeout

Description of "Figure 6-4 Asynchronous Interaction with Timeout"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of an asynchronous transaction with a timeout, it needs an invoke activity to send the request and a pick activity with two branches: an onMessage branch and an onAlarm branch. If the reply comes after the time limit has expired, the message goes to the dead letter queue. As with all partner activities, the WSDL file defines the interaction.
For more information about asynchronous interactions with a timeout, see Section 14.2, "Creating a Pick Activity to Select Between Continuing a Process or Waiting."

BPEL Process Service Component as the Service

The behavior of the BPEL process service component as a service is equal to the behavior with the asynchronous interaction with the BPEL process service component as the service.

6.5 Introduction to Asynchronous Interactions with a Notification Timer

In an asynchronous interaction with a notification time, a client sends a request to a service and waits for a reply, although a notification is sent after a timer expires. The client continues to wait for the reply from the service even after the timer has expired. Figure 6-5 provides an overview.

Figure 6-5 Asynchronous Interaction with a Notification Time

Description of "Figure 6-5 Asynchronous Interaction with a Notification Time"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of this transaction, it needs a scope activity containing an invoke activity to send the request, and a receive activity to accept the reply. The onAlarm handler of the scope activity has a time limit and instructions on what to do when the timer expires. For example, wait 30 minutes, then send a warning indicating that the process is taking longer than expected. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

The behavior for the BPEL process service component as the service is equal to the behavior with the asynchronous interaction with the BPEL process service component as the service.

6.6 Introduction to One Request, Multiple Responses

In this interaction type, the client sends a single request to a service and receives multiple responses in return. For example, the request can be to order a product online, and the first response can be the estimated delivery time, the second response a payment confirmation, and the third response a notification that the product has shipped. In this example, the number and types of responses are expected. Figure 6-6 provides an overview.

Figure 6-6 One Request, Multiple Responses

Description of "Figure 6-6 One Request, Multiple Responses"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of this transaction, it needs an invoke activity to send the request, and a sequence activity with three receive activities, one for each reply. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

The BPEL service needs a receive activity to accept the message from the client, and a sequence attribute with three invoke activities, one for each reply.

6.7 Introduction to One Request, One of Two Possible Responses

In an interaction using one request and one of two possible responses, the client sends a single request to a service and receives one of two possible responses. For example, the request can be to order a product online, and the first response can be either an in-stock message, or an out-of-stock message. Figure 6-7 provides an overview.

Figure 6-7 One Request, One of Two Possible Responses

Description of "Figure 6-7 One Request, One of Two Possible Responses"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of this transaction, it needs the following:

• An invoke activity to send the request
• A pick activity with two branches: one onMessage for the in-stock response and instructions on what to do if an in-stock message is received
• A second onMessage for the out-of-stock response and instructions on what to do if an out-of-stock message is received

As with all partner activities, the WSDL file defines the interaction.
For more information about interactions using one request and one of two possible responses, see Section 14.2, "Creating a Pick Activity to Select Between Continuing a Process or Waiting."

BPEL Process Service Component as the Service

The BPEL service needs a receive activity to accept the message from the client, and a switch activity with two branches, one with an invoke activity sending the in-stock message if the item is available, and a second branch with an invoke activity sending the out-of-stock message if the item is not available.

6.8 Introduction to One Request, a Mandatory Response, and an Optional Response

In this type of interaction, the client sends a single request to a service and receives one or two responses. Here, the request is to order a product online. If the product is delayed, the service sends a message letting the customer know. In any case, the service always sends a notification when the item ships. Figure 6-8 provides an overview.

Figure 6-8 One Request, a Mandatory Response, and an Optional Response

Description of "Figure 6-8 One Request, a Mandatory Response, and an Optional Response"

BPEL Process Service Component as the Client

When the BPEL process service component is on the client side of this transaction, it needs a scope activity containing the invoke activity to send the request, and a receive activity to accept the mandatory reply. The onMessage handler of the scope activity is set to accept the optional message and instructions on what to do if the optional message is received (for example, notify you that the product has been delayed). The client BPEL process service component waits to receive the mandatory reply. If the mandatory reply is received first, the BPEL process service component continues without waiting for the optional reply. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

The BPEL service needs a scope activity containing the receive activity and an invoke activity to send the mandatory shipping message, and the scope's onAlarm handler to send the optional delayed message if a timer expires (for example, send the delayed message if the item is not shipped in 24 hours).

6.9 Introduction to Partial Processing

In partial processing, the client sends a request to a service and receives an immediate response, but processing continues on the service side. For example, the client sends a request to purchase a vacation package, and the service sends an immediate reply confirming the purchase, then continues on to book the hotel, the flight, the rental car, and so on. This pattern can also include multiple shot callbacks, followed by longer-term processing. Figure 6-9provides an overview.

Figure 6-9 Partial Processing

Description of "Figure 6-9 Partial Processing"

BPEL Process Service Component as the Client

In this case, the BPEL client is simple; it needs an invoke activity for each request and a receive activity for each reply for asynchronous transactions, or just an invoke activity for each synchronous transaction. Once those transactions are complete, the remaining work is handled by the service. As with all partner activities, the WSDL file defines the interaction.

BPEL Process Service Component as the Service

The BPEL service needs a receive activity for each request from the client, and an invoke activity for each response. Once the responses are finished, the BPEL process service component as the service can continue with its processing, using the information gathered in the interaction to perform the necessary tasks without any further input from the client.

6.10 Introduction to Multiple Application Interactions

In some cases, there are more than two applications involved in a transaction, for example, a buyer, seller, and shipper. In this case, the buyer sends a request to the seller, the seller sends a request to the shipper, and the shipper sends a notification to the buyer. This A-to-B-to-C-to-A transaction pattern can handle many transactions at the same time. Therefore, a mechanism is required for keeping track of which message goes where. Figure 6-10 provides an overview.
As with all partner activities, the WSDL file defines the interaction.

Figure 6-10 Multiple Party Interactions

Description of "Figure 6-10 Multiple Party Interactions"

When to use OSB and When use BPEL

Oracle OSB:  If the primary requirement is for a solutions to accomplish  content based routing,transformation,message validations,enrichments and the integration is enterprise wide and features like message throttling,service virtualization,Reliable messaging are important,the Oracle Service Bus is a great fit .

Oracle BPEL: If the requirement is for a solution to design, manage and run business processes which are stateful with functionalities like Human Workflow,Business Rules,monitoring and management and composite service implementations,the choice should be BPEL.

Java Emberd in Oracle SOA BPEL Notes

Reference Links:

• Create a PDF report from java jar file and call this jar file from BPEL process
• Set instance name from java emberd
• 
  

Steps to Invoke Asynchronous webservice from Oracle SOA

In earlier post we have seen how to create Asynch Webservice(BPEL Process) and test this Asynch service using SOAP UI.

In this post we will see how to call the Asynch Webservice(BPEL Process) within the SOA.

Here we invoke the Asynch service as syncronus webservice and only difference is we need to set the "replyToAddress".

replyToAddress = Callback URL.

Background:
Step 1. Create a Asynchronous webservice - link for reference

Step 2. Create a webservice for the client call back.
               * This service is required to be created in client end such that Asynch service which is                              created in            step 1 can replyback to the client.
               * This service should be created based on the schema of callback port of asych webservice.

Step 3: a. Create a new BPEL service which invokes the Asynchronous webservice created in step 1
            b. Set the invoke property replyToAddress to the wsdl address of client webservice ie.,                             created in Step2

Create Asynchronous Webservice in Oracle SOA BPEL

We use the Asych Webservice for better performance for overall system.


Oracle SOA BPEL Asyncronus project can be downloaded from here

SOAPUI Project to invoke the Asynch ORacle SOA Webservice BPEL process can be downloaded from here

Steps Followed:
1. Create a SOA Project
2. Drag a BPEL process with the Template define later
3. Drag a websive with template as Asynchronous and provide the input xsd and callback post input xsd mapping check the below screenshot

4. Connect the Asynch webservice with the BPEL process.

5. Do a process in bpel and invoke the call the call port as below

6. Test the Asyncronus composite by following below steps using SOAPUI.

Asynchronous Web Service Testing in soapUI

When invoking an asynchronous web service, the caller must provide a callback for the response. Since our testing will originate from soapUI, then it is only natural that soapUI would provide the callback mechanism. This mechanism in soapUI is called a MockService. In a nutshell, a soapUI MockService is a simulation of a Web Service (aka, a process listening on a port). We will go through the steps in setting up the MockService for a simple asynchronous BPEL process.

After creating your soapUI project based on an asynchronous BPEL process, you will see something like the following:

Notice that soapUI created an interface for both the request and the response (i.e., callback). The interface that was created for the callback will be used to create the MockService. Right-click on the callback interface and select the Generate MockService menu item:

You will be presented with the Generate MockService dialogue where we will tweak the Path and possibly the port (depends upon what ports are available on the machine where soapUI will be running). We will adjust the Path to include the operation name (append /processResponse in this example) and the port of 8088 is fine:

Once the MockService is created, you should have something like the following in soapUI:

This window acts as a console/view into the callback process. When the play button is pressed (green triangle in the upper left-hand corner), soapUI will start a process running on the configured Port that will accept web service invocations on the configured Path:

At this point we are “almost” ready to try out the asynchronous test. But first we must provide the web service addressing (WS-A) configuration on the request message. We will edit the message for the request interface that was generated when the project was created (SimpleAsyncBPELProcessBinding > process > Request 1 in this example). At the bottom of the request message editor you will find the WS-A configuration by left-clicking on the WS-A label:

Here we will setup WS-A by changing the default values to:

1. Must understand: TRUE
2. Add default wsa:Action: Add default wsa:Action (checked)
3. Reply to: ${host where soapUI is running}:${MockService Port}${MockService Path} … in this example: http://192.168.1.181:8088/mockSimpleAsyncBPELProcessCallbackBinding/processResponse

We now are ready to run the asynchronous test from soapUI free edition. Make sure that the MockService you created is running and then push the play button for the request (green triangle in the upper left-hand corner of the request editor). If everything is configured correctly, you should see the response show up in the MockService window:

To view the response message/payload, just double-click on a response message in the Message Log window of the MockService:

At this point you can now expand the project to include a Test Suite for some load balance tests etc. This same topic has been covered in various detail on other sites/blogs, but I wanted to simplify and detail how this is done in the context of SOA Suite 11g. It also serves as a nice introduction to another blog of mine

Oracle SOA BPEL Transaction Option in Asynchronous BPEL

Asynchronous BPEL process is helpful in achieving higher performance of the system. While connecting the ASynch Webservice to the BPEL process we have  following transaction options

By default, incoming requests are saved in the following delivery service database tables: dlv_message

• async.persist: Messages are persisted in the database.

• sync.cache: Messages are stored in memory.

• sync: Direct invocation occurs on the same thread.

We need to select the transaction option based on requirement mainly based on recovery process.

If the process failed in the Asyncronus process then we can resubmit that process instead of restarted from the beginning.

Oracle SOA BPEL Validate activity usuage

The validateXML property validates incoming and outgoing XML documents. If set to True, the Oracle BPEL Process Manager applies schema validation for incoming and outgoing XML documents. Nonschema-compliant payload data is intercepted and displayed as a fault.

How to apply OWSM security in Oracle SOA BPEL

Service we expose need to secured when it is consumed by the client out of the organization. We can apply OWSM security to access the service by providing the username/password.

There are two ways mentioned below to apply OWSM policy to SOA service.

• Apply OWSM policy during design time using Jdeveloper
• Apply OWSM policy from  em console

Good info from:
http://eelzinga.wordpress.com/2010/05/14/oracle-soa-suite-11g-resequence-messages-in-mediator/

Example for Mediator Resequencing

http://eelzinga.wordpress.com/2010/05/14/oracle-soa-suite-11g-resequence-messages-in-mediator/

In realtime we use the resequnce for Order fulfillment. Where order id is used as group id and unique id is used as sequence id.

Order fulfillment usually has many stages each stage is passed to end service in sequential order by using resequencing option in mediator. Eventhough the status update the Order fulfillment we receive from the client is random we make it sequential.

Oracle SOA Registry Quick Notes

1. OER: Acts as the single source of truth for information surrounding SOA assets and their dependencies.

Ie., for reusing the service we can search the OER as single trusted repository and we can also see all the dependencies for that composite in OER

2. OSR: Oracle Service Registry provides a 'DNS'-like reference for SOA runtime infrastructure to dynamically discover and bind to deployed services and end points.

Below resouce provide the detail of how to install OSR and how to harvest the composite to OSR from JDeveloper.
http://biemond.blogspot.co.uk/2009/12/using-oracle-service-registry-in-soa.html

Oracle SOA Oneway SSL Client configuration

Source: http://theheat.dk/blog/?p=474
With little modification I have posted below one way ssl configuration for Oracle SOA for my reference.

Oneway SSL configuration: 

Requirment is to setup the MW client to call the secured server through SSL. One way SSL means client will make sure that it is calling the correct server ie., server identification is enforced in oneway ssl. Eg is acceing Bank Online Site from broswer, we make sure that we  are calling the exact Bank website instead of fradulent one.

What Happens When a Client Encounters SSL

1. The client requests that the server identify itself.
2. The server sends the client a copy of its SSL Certificate.
3. The client checks whether it trusts the SSL Certificate. If so, it sends a message to the server.
4. The server sends back a digitally signed acknowledgement to start an SSL encrypted session.
5. Encrypted data is shared between the browser and the server and https appears.

You have to configure 3 things in Oracle SOA EM:

1. Djavax.net.ssl.trustStore

Djavax.net.ssl.trustStore must point to your truststore in setDomainEnv.sh.
For example:
-Djavax.net.ssl.trustStore=/u01/app/oracle/domains/my_domain/keystores/soa_trust.jks
I don’t know why this is necessary since we also set this in the next step but it does not work if you don’t.
2. Set Keystore location in the SOA SuiteStart the FMW Control EM and navigate to the SOA Suites Managed Server. Right click and select SOA Administration and then Common Properties.Choose “More SOA Infra Advanced Configuration Properties” at the bottom.Press the “KeystoreLocation” link.Input the path to the keystore and press Apply.3. Set Keystore password in the SOA SuiteNavigate to Weblogic Domain and select your SOA Suite Domain. Right click and select Security and then Credentials.Press Create Map and input SOA. It must be SOA to work.Press Create Key and input:

• Map: SOA

• Key: KeystorePassword

• User Name: KeystorePassword

• Password: Password for the soa_trust.jks keystore.

It must be KeystorePassword for both Key and User Name to work.

Additional Point:Create map with name SOA, into this map create key with name KeystorePassword, user KeystorePassword and the password of the keystore. Create a 2^nd Key KeyPassword, user KeyPassword with password and the keystore password.

TestWhen you start the Managed Server the .out log file should look like this:
INFO: SSLSocketFactoryManagerImpl.getKeystoreLocation SOA Keystore location: /u01/app/oracle/domains/my_domain/keystores/soa_trust.jks
INFO: SSLSocketFactoryManagerImpl.getKeystorePassword Obtained valid keystore password
INFO: SSLSocketFactoryManagerImpl.getKeyPassword Obtained null or empty key password
We have only input the password for the keystore not the key so it is OK that it cannot find this.
If you have input something wrong it looks like this:
INFO: SSLSocketFactoryManagerImpl.getKeystoreLocation SOA Keystore location: /u01/app/oracle/domains/my_domain/keystores/soa_trust.jks
INFO: SSLSocketFactoryManagerImpl.getKeystorePassword Obtained null or empty keystore password
INFO: SSLSocketFactoryManagerImpl.getKeyPassword Obtained null or empty key password
INFO: SSLSocketFactoryManagerImpl.getSSLSocketFactory Could not obtain keystore location or password
You can find more information here. This is for Two-way SSL but the steps are the same.

Oracle SOA JMS Error Quue Handling

Requirment:

Message is queue need to be deleted after 7 days and need to be archived.

Solution:

We have a Oracle SOA service which pushes the messages to the JMS Queue. Requirment is this message need to be deleted and archived after 7 days

Steps followed:

1.  Add a time to like for the JMS Queue(InQueue) in BPEL JMS Apadtor of the JMS producer composite

     2.       Define the New Error Queue (ErrQueue) in EM console. 

     3.      For InQueue Select “Redirect” as expiration policy and select the “Error Destination” as the queue which is created in step 2.

By this way if the JMS message is older than 7 days(Or any configurable days) in InQueue it can be redirected/logged to new ErrQueue

Like to highlight the different expiration policy available for us to choose from.

None - Same as the Discard policy; expired messages are simply removed from the destination.
Discard - Removes expired messages from the messaging system. The removal is not logged and the message is not redirected to another location. If no value is defined for a given destination (i.e., None), then expired messages are discarded.
Log - Removes expired messages from the system and writes an entry to the server log file indicating that the messages have been removed from the system. The actual information that is logged is defined by the Expiration Logging Policy.
Redirect - Moves expired messages from their current location to the Error Destination defined for the destination. The message retains its body, and all of its properties. The message also retains all of its header fields, but with the following exceptions:

·         The destination for the message becomes the error destination.

·         All property overrides associated with the error destination are applied to the redirected message.

·         If there is no Time-To-Live Override value for the error destination, then the message receives a new Expiration Time of zero (indicating that it will not expire again).