Powered By Blogger

Saturday, September 21, 2013

UMS Email driver Errors

In this post, I would like to share two UMS errors and their solutions

Error#1

ID 1341107.1Error status received from UMS.[[
Status detail :
         Status type : DELIVERY_TO_DRIVER:FAILURE,
         Status Content : No matching drivers found for sender address = EMAIL:soaadmin@example.com,
         Addressed to : EMAIL:user1@example.com,
         UMS Driver : null,
         UMS Message Id : 1823d47b0a58948725252c998e082228,
         Gateway message Id : null,
         Status Received at : Thu Jul 25 16:22:16 PDT 2013.
Check status details and fix the underlying reason, which caused error.

Cause: The UMS Driver for the appropriate channel(Email) is configured with a specific list of
SenderAddresses, and the message sent by the application has a Sender Address that does not
match.

Remedy: Make the Sender Address blank. This will ensure that all outbound messages will be sent
regardless of the sender address.

Error#2

Error Message: ORABPEL-31023 - Cannot send email notification to address. The
address is being marked as invalid and no further notification would be sent to this address.
 

Cause: Due to a number of previous failed send attempts to an email address, SOA Suite has
added the address to the Bad Address List thus preventing subsequent sends to this address from
failing. The previous failed attempts may been caused by a configuration issue.

Remedy: Remove the email address from the Bad Address List. This can be done by selecting View
Bad Addresses from the Notification Management page in Enterprise Manager. When the Bad Address
List dialog box is displayed, remove the email address from this list.

Thursday, September 19, 2013

java.sql.SQLException: ORA-25215: user_data type and queue type do not match

I would like to discuss possible causes that might throw error in subject

Above error comes when AQ adapter  is used from middleware point of view

As error is reminiscent, first obvious reason is AQ user data type in Oracle Apps is different than what AQ adapter is expecting from SOA composite.If you change AQ data type after deploying composite then re-run the AQ adapter wizard to sync up AQ data type definitions

Even after making sure above all is correct, if we still see error then following case also causes above error

If we drop and recreate AQ /data type definitions in Oracle Apps then SOA log throws errors for some time and stops. SOA should recover from this error after some time or DBA can also flush the database cache to recover quickly

Hope this helps

Sunday, September 15, 2013

XML-22036: (Error) Cannot convert result tree fragment to NodeSet

In this post we talk about context of error in subject.

XSLT 1.0 spec has a data type called 'result tree fragment' and this data type is introduced by XSLT variables.A result tree fragment is treated equivalently to a node-set that contains just a single root node. However, the operations permitted on a result tree fragment are a subset of those permitted on a node-set.In particular, it is not permitted to use the /, //, and [] operators on result tree fragments

For example, if we have xslt like below then that is scope for  mentioned error

 <xsl:stylesheet version="1.0"....
 <xsl:param name="InputVariable.payload" />
 <xsl:template match="/">
 <top:ResultTreeCollection>
 <top:Application>
  <xsl:value-of select="$InputVariable.payload/ns1:Applications/ns1:ApplicationName" />
  </top:Application>
...
</xsl:stylesheet>

In above XSLT, we are trying to access a BPEL variable called  "InputVariable"(having result tree fragment data type) and applying an operation '/' which is not allowed as per XSLT 1.0 spec

There are two solutions possible
  • Using Oracle xslt extension function node-set() which converts result tree fragment to node set
  • Use XSLT 2.0 version
Simplest solution is use XSLT 2.0 version  that means,  <xsl:stylesheet version="2.0">         2.0 version deprecates result tree fragment data type and implicitly convert that to node-set data type on which /, //, [] operations are allowed safely.

Same error comes when xsl:variable is defined to have sequence of nodes. For example <xsl:variable name="Applications" select="./ApplicationsList" />

Friday, September 6, 2013

Weblogic JMS Message Throttling

In this post, we will see how can we setup weblogic JMS message throttling.
There are three possible setups to implement this feature
  1. Flow control (used for message producer)
  2. JCA property(used for message consumer)
  3. Work managers(used at thread level)
We need not implement all three but which one to use depends upon requirements

Message throttling setup is really required for following reasons
  1. To prevent resource monopolizing
  2. To maintain good server health, ultimately preventing unexpected server downs
  3. Preventing resource starvation
For example, let's take a very common scenario in IT environments.If message consumer is down for routine maintenance and producer is up and producing huge number of messages then by the time consumer comes back online there will be huge number of messages piling up.
If there is no flow control enabled then, by default WLS creates many threads to meet the demand  which intern will start consuming all server resources just to process pending JMS messages.This will ultimately lead to resource starvation for other threads/processes running in the server.


Steps required to setup flow control

This can be achieved by two level setups
  1. Threshold setup on Queue under JMS module (Here we define min/max thresholds which triggers message throttling)














 2.  Connection factory flow control setup(Here we define how message producer should behave in case of threshold event)

















How it works?

When thresholds defined on destination reached(for example, max no of messages on a destination reached), since we have enabled "flow control" on connection factory, throttling will kick off automatically.Producers created using that CF will be instructed to control their message production as per numbers defined on CF.

Once Flow control kicks in, it will instruct message producer how fast or slow he has to produce messages to meet consumer speed.There will be no instructions provided to control consumer speed

Flow Maximum: Indicates how many messages a producer can generate per second when system is under flow control event

Flow Minimum: System will not slowdown producer further, if he is already generating messages per second equivalent to this value

Flow Interval: In how many seconds producer will come down from Flow Maximum to Flow Minimum, when system is under overloaded.It is a cool down period.In stead of rapid decreasing in production, producer goes steady slowdown causing smooth transition.

Flow Steps: Again second level of smooth transition.In how many breaks it will adjust flow interval
For example, if flow interval is 60 secs and flow steps is 10  then  60 divided by 10 = 6
in 6 breaks/pauses it will cool down the producer.

Throttling messages from consumer side
In a clustered environment, set following properties in consumer JMS JCA file 
<property name="minimumDelayBetweenMessages">10000 </property>

Delay is mentioned in milliseconds
Above properties causes JMS adapter to post messages to composite keeping 10000 secs gap between each message consumption.

Work managers
Though I have never tried this option,I believe we can throttle message processing using work managers also.Work managers is a weblogic way of expressing how client requests should be scheduled and processed.
Work managers can be defined and associated with deployment descriptors at various levels like domain(config.xml),application (weblogic-application.xml),EJB module level(weblogic-ejb-jar.xml) and web application(weblogic.xml)

As of version 11.1.1.6, we cannot associate work managers to BPEL composites  but can be assigned to OSB proxy and business services
I would recommend to explore this option too

Hope this helps