Periodically Oracle releases some bundle patches over SOA versions like 11.1.1.5 and 11.1.1.6.
These patches are recommended and tested and you can find them in a single place by looking at the article 1485949.1 at MyOracle Support
Sometimes, even when working with Java, you have to rely on native code. An example of this is when you have to use a shared library and call it via Java using JNI.
I passed by this situation recently when itegrating with SAP ERP via JCo, which uses internally a shared library to access SAP. This can be painful if you mess 32 and 64-bit library versus JVM and you will get only UnsatisfiedLinkError which is the same error you get when the library is not found, making troubleshooting really hard.
So, to avoid all this confusion, the first step is to understand if your JVM is 32 or 64-bit. After that, you have to understand if your library is 32 or 64-bit and you can do that using the file Linux command over the file of the library and make sure the architecture of the library match the one of the JVM.
For example, by running file command over the SAP JCo 32-bit library, we have the following output, showing it's 32-bit
libsapjco3.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
In this case, you have to make sure your JVM architecture matches. The last step in working with shared libraries in Linux after you know the architecture of the library match the JVM's, is to make sure the path where the library resides is added to the LD_LIBRARY_PATH variable.
In a recent engagement I was faced with the challenge of using Apache ActiveMQ for the first time. After learning a little bit about ActiveMQ, I had to connect to it from Oracle WebLogic Server for message consumption, so I decided on using a Foreign Server configuration.
Well, the first part of this is to add the libraries of ActiveMQ to WebLogic's classpath. I had to add the following libraries to my DOMAIN\lib directory (I'm using ActiveMQ 5.5.1):
XML Feedsactivemq-core-5.5.1.jarlog4j-1.2.14.jarslf4j-api-1.5.11.jarslf4j-log4j12-1.5.11.jarosgi.core-4.3.0.jarThe OSGI JAR does not come with Apache ActiveMQ and was downloaded directly from http://www.osgi.org. It's necessary due to the fact that ActiveMQ has some services based on OSGi APIs which are registered during startup.
After that, we need to configure the Foreign Server. For the Foreign Server, we specify the Initial Context Factory, URL for the ActiveMQ and some properties to configure how ActiveMQ will understand / emulate JNDI lookups performed by WebLogic Server.
Values that should be provided during the Foreign Server configuration:
As mentioned above, we should specify the JNDI Properties during configuration of the Foreign Server as it will guide how the JNDI lookups are made.
ActiveMQ provides the support for JNDI through the specification of properties specified during the Initial Context Factory creation. For example, to specify the name of the JMS Connection Factory you use a property called connectionFactoryNames and specify the names as a list of comma-separated values and the name of the queues and topics follow the convention queue/topic.JNDIName=PhysicalName. For more info, click here.
For example, if you have a queue named myQueue in ActiveMQ, and specify the following as the properties:
connectionFactoryNames=MyConnectionFactory
queue.myQueue=myQueue
A connection factory with JNDI name MyConnectionFactory and a queue jndi named myQueue will be available for lookup.
The following image shows the final configuration of the Foreign Server for our sample:
Now, we just map the remote destination (queue and/or topic) and connection factory names to local names, what allows us to create a level of abstraction. Each one of these settings are configured in the respective tab of the Foreign Server configuration.
Bellow, we see both images with the configuration of Destinations and Connection Factories.
In the configuration shown, we changed the local names of the queue and connection factory by adding a jms. in front of the JNDI name.
If we look at the server's JNDI tree, we see our both objects coming from ActiveMQ:
And clicking one of the links in the JNDI tree view, we see the objects are instances of ActiveMQ classes:
Well, that's it! Now, it's just a matter of looking the objects up from WebLogic itself and using them without caring if they are remote or not.
We saw in the last post the role played by Message Delivery & Recovery in SOA Suite Architecture. 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.
BPEL message delivery is an important subject in any architecture based on Oracle SOA Suite specially when dealing with asynchronous processes. I aim to show some pieces on how the message delivery works and how to perform recovery when things don’t go so well.
Understanding message delivery & recovery
In Oracle BPEL PM, synchronous messages are processed in the same thread they are received and if an error is thrown it’s propagated back and the caller knows instantaneously that a problem happened and can retry or take some corrective action.
Life is not so easy, though, when dealing with asynchronous (one way or async request response) processes. As the caller does not wait for an instantaneous response, there’s no way for it to know that a problem has happened. When asynchronous messages are received, assuming the default asynchronous delivery policy is in use, they are persisted and scheduled for execution. Then, they are executed by a different thread than the one which received the request.
Oracle BPEL takes care of the message delivery for async scenarios and, in case of problems, the transaction that encompasses the delivery is rolled back and so does the message delivery state. The instance is put back to the last dehydration point. If this situation happens, you have to recover (manually or automatically) the messages so that it’s scheduled for delivery again and retried since the last dehydration point.
For example, the process bellow will always cause the message to be rolled back to the last dehydration point as we throw a rollback exception. It’s not a very useful process but a good sample as you can easily explore the recovery behavior with it. The last dehydration point in this case is the message being placed back into the queue as an undelivered invoke message. Message type is Invoke as it’s the message responsible for instance creation that is being rolled back and there’s no other dehydration point before the error occurs.
The process flow is very straightforward: it’s a one way process and we are using the default async delivery policy, so it’s first persisted and then scheduled for delivery. The process receives a message and forces the rollback by throwing a rollback exception. This causes the transaction that encompasses the execution of this process to be rolled back and the message is put back as undelivered in the corresponding database table:
Details of the exception thrown to force the rollback:
There are many reasons which cause the transaction rollback and leave the message to be recovered in the real world. Don’t think you have to throw rollback exception to accomplish this; we just used this approach to make it easy to test the scenario. Any situation that causes the main transaction which encompasses the flow execution to rollback will put the message as pending recovery, including scenarios where no exception is thrown but the transaction is propagated and rolled back by a remote component (e.g. EJB), for example.
Even situations when no rollback is performed but when SOA Suite is overloaded will cause messages to go straight to delivery queue instead of being scheduled for processing, so a good understanding on how this scheme works is mandatory for a resilient architecture.
Performing Recovery
Recovery can be done by accessing the BPEL Engine page, under SOA Infrastructure and then accessing the Recovery tab as seen bellow:
You can then filter based on the Type of the Message, Duration and Message State. If the message is Recoverable, the Recovery column will show that and you can click its line and then click Recover. If the situation which caused the message to remain in recovery is gone, it will be successfully recovered and will disappear from this list. Our sample process can’t be recovered as it will always rollback and remain as undelivered.
You can also schedule recovery so it will be performed automatically and you can also determine limits on how many times the recovery can be tried for a message but this is theme for another post.
:: Next >>