Moreover, because it is a pseudo queue on sending server, you could even have the JNDI of the queue different than the actual JNDI of the queue on remote server. This means, in my scenario, I could create a pseudo local JNDI for EDNQueue (JNDI: jms/fabric/EDNQueue); but have it forward to a regular JMS queue with a different JNDI (other than jms/fabric/EDNQueue) on the SOA server. This is a consideration if you want to get away from some of the inherent limitations of EDN subscriptions.
Here is how you do it.
Preparing ADF server for EDN:
This step is specific to ADF applications on non-SOA domains that want to use EDN. For steps to create an ordinary SAF, go to next section.
1. Copy the two directories oracle.soa.fabric_11.1.1 and oracle.soa.workflow_11.1.1 to the non-SOA server. We will be deploying these as shared libraries on the non-SOA servers. Make sure these folders are copied to the same location. These servers bring the EDN capabilities to a regular weblogic. These folders can be found under /oracle_soa_home/soa/modules of a SOA domain.
2. From non-SOA server console, go to deployments and deploy these shared libs by browsing and selecting oracle.soa.workflow_11.1.1/oracle.soa.workflow.wc.jar
3. Complete the steps and make sure the jars are showing up on the console.
Receiving SOA server:
Create the queue on the server to which JMS messages need to be forwarded. In my case, queue is TestEDNQ.
Sending ADF server:
This is where we will be creating the SAF mechanism to forward messages to TestEDQ on the receiving server.
1. Create a SAF agent from weblogic console of the server. Services>Messaging>Store-and-Forward Agents. Create new, give a name, and select an appropriate 'Agent Type'. I am leaving this as 'both'. Pick a value based on the purpose of this agent to either send, receive or both SAF messages.
2. Create a jms server and jms module they doen't exist. Services>Messaging>JMS Servers and Services>Messaging>JMS Modules.
3. Create a sub deployment for the jms module and specify the target to a JMS server.
4. Create a SAF remote context. This is the connection to the remote receiving server. From within jms module, click new> select 'Remote SAF Context'> Specify a name, t3 URL to the remote server, user name and password. In the screenshot below, I am setting up my remote context to weblogic at localhost:7101
5. Create SAF imported destinations. This is a collection of queues and topics that can share the same SAF remote context. From within jms module, new>select 'SAF Imported Destinations', specify a name, select the remote SAF context that got created in previous step. Leave the default targeting and finish.
6. Created SAF remote context and imported destinations should look like this:
7. Create SAF queue. This is where we specify the remote queue and JNDI. In my case, I am trying to forward an EDNQueue to a regular JMS queue on the remote server. Hence, I have different values for local and remote JNDIs. However, if remote queue's JNDI is what you need on local server also, ignore the local JNDI value in this configuration. Click on the created SAF Imported Destinations > go to queues tab> 'New' and enter remote queue name and remote queue JNDI. Click OK.
8. Once created click on the created queue and add additional configuration. There is where I am overdiding remote JNDI with a different JNDI name locally on this server. My local JNDI is that of the EDNQueue and remote JNDI is that of the queue to which I want to forward my events (JMS messages).
9. Send a test JMS message to jms/fabric/EDNQueue and it will get forwarded to JMS/TESTEDNQ on the remote server. Important note here is that there is no local physical queue on the sender. All you do is, with the SAF configuration, you create a reference to a remote queue and SAF will store the message and forward it to the queue based on its availability.
10. Optionally, error handler can also be configured for SAF destinations.
Posts
