Configuring SAF JMS Resources

store and forward agents (SAF) in WLS is a mechanism by which WLS local JMS producers produces messages to remote JMS destinations. These remote JMS destination can be part of  other domain/machine/cluster.

Main steps involved are

1. Create SAF agent
2. Create SAF remote context
3. Create SAF imported destination
4. Configuring SAF  imported destination with remote Queues and Topics

 Create SAF agent
SAF agent is a component which  is responsible for storing and forwarding messages between local sending and remote receiving destinations
It stores messages locally when remote destination is not reachable and forwards it when remote destination is available.
We are trying to produce JMS messages to remote destination ; hence it is required
Provide appropriate values when creating SAF agent and make sure you select 'Sending Only' for agent type field.

Create SAF remote context
 SAF remote context holds connecting url and credential information to connect to remote WLS instance.

1. Login to WLS console and navigate to Services> Messaging>JMS Modules, click on required JMS module<SOAJMSModule> on which you want to create this resource
2. Click New button and select 'Remote SAF Context', click Next
3. Specify required information and click OK

Note: URL format can be :// host:port, for example http://server1:8001

Create SAF imported destination

SAF imported destinations are collections of SAF queues and topics that locally represent JMS queues or topics on a remote server instance or cluster

1. Login to WLS console and navigate to Services> Messaging>JMS Modules, click on required JMS module<SOAJMSModule> on which you want to create this resource
2. Click New button and select 'SAF Imported Destination', click Next
3. Provide any valid JNDI prefix, example safjms. and select remote SAF context created in previous step,click next
4. Click Advanced Targeting and select one of subdeployments from list and make sure this resource is targeted to SAF agent created in 1st step.(To understand what we are doing here you need to understand JMS sub deployment mechanism in WLS)
5. Click Finish

Configuring SAF  imported destination with remote Queue and Topics

 Now we have to associate remote JMS destinations with SAF imported destinations

1. Click on created SAF imported destination
2. Click on either Queues or Topics tab depending on type of resource you would like to access remotely
3. Provide Remote JNDI name(This should exactly match the remote JMS destination JNDI) and click OK
4. Now click on newly created resource and provide any valid local JNDI name for example saf.localjndi and click Save

Now you are ready to produce  messages to remote JMS destinations using local JMS producers

Note: Please use local JNDI prefix + local JNDI name to produce messages locally, in our case it becomes  safjms.saf.localjndi. To consume messages consumer has to use remote JNDI.

DEV_MDS.MDS_INTERNAL_SHREDDED has errors

This article is about to discuss an issue I faced during starting of SOA11.1.1.4 server on top of XE database.

After installing SOA 11.1.1.4 on top of XE database and when I start admin server I started seeing below error message.
One more indication which confirms this issue is when we create a connection in Jdev we can not see any MDS  partitions to connect to the server.

Circumstance: When SOA 11.1.1.4 is installed on XE database and when we start admin server/managed server


This error is specific to XE db

Error
Caused By: oracle.mds.exception.MDSExceptionList: MDS-01329: unable to load element "persistence-config"


MDS-01370: MetadataStore configuration for metadata-store-usage "soa-infra-store" is invalid.
ORA-04063: package body "DEV_MDS.MDS_INTERNAL_SHREDDED" has errors

ORA-06508: PL/SQL: could not find program unit being called: "DEV_MDS.MDS_INTERNAL_SHREDDED"

If you try to compile above procedure and if error is

Error(1): PLS-00753: malformed or corrupted wrapped unit, then you can simply apply below solution

Solution:
1) Use RCU to drop the SOA Suite schemas and tablespaces


2) Set the environmental variable RCU_JDBC_TRIM_BLOCKS=TRUE and then run RCU again to re-create the SOA Suite schemas and tablespaces

OSB 11g "Test Console" service is not running

We use OSB test console application to test Proxy/Business services before moving them to production.
When we install OSB for production mode then there is a separate 'osb_server1' managed server is installed.
Starting this server is mandatory to use 'test console'.
If you start working on designing OSB services without starting 'osb_server1' then all your changes are partially activated. You can check this on OSB console.

So when you 'click test console' before starting osb_server1 we see an error like

Error Accessing Test Configuration
"Test Console" service is not running. Contact administrator to start this service.
 
Solution to this is starting osb_server1.
If you still see error, then follow below step too.

Try setting the Admin server listen address to a specific valid address, such as localhost.
In the Oracle WebLogic Server Console, go to Environment > Servers > admin_server_name  > Configuration > General to set the Listen Address.
 
If OSB server is installed for development mode, then you will not have this problem.