OSB - Using DVM in 12c using qualifiers

To use a DVM in OSB 12c which requires qualifiers, specify the function as such:

dvm:lookupValue(dvm-location, src-column, src-value, target-column, default-value, qualifiers[])

dvm:lookupValue('DVMQualifiers/Proxy/dvm-cities', 'CityCode', 'KN', 'CityName', 'NA', ('Country','USA'))

SOA - Unable to edit file/jms/db adapter; shows red cross mark

Problem:
Migrated composites to the 12c version are unable to be edited, even with the <?binding.jca dbAdapter_db.jca> fix. The adapter is also showing a red cross mark.

Solution:
The solution is provided in this Oracle community post:

Open .jca file for JMS adapter  and change from  adapter="JMS Adapter" to adapter="jms" . If you use database adapter as well , then change from adapter="Database Adapter" to adapter="db". (  ... adapter="File Adapter" to adapter="file")

The adapter is now able to be edited normally.

FYI - JMS Polling and Error Queues

FYI:

When polling a JMS queue in OSB, in order for it to go to the configured error queue, an error must be raised. Raising an error and then handling this error won't cause the message to be sent to the error queue. If the error is handled, then a fault must be raised again.

Take this simple proxy service as an example that polls from a JMS queue configured in weblogic and calls a stored procedure to insert the polled record:

EmployeePS Pipeline:

Should an unexpected error occur somewhere in this pipeline, it will be caught by the error handler. The error will be reported in the EM Message Reports but the error is raised again so that it can be sent to the error queue.

Doing a Reply with Failure will NOT send the message to the error queue. As explained by AbhishekJ here:

In case of JMS transport the JMS Queue or Topic will receive a NACK back but the message will NOT roll back and will be removed from the destination just like in case of Reply with Success. This happens because using a Reply action is considered as an exception being handled properly and a commit will be sent back to the JMS destination. To roll back the message ensure that you use Raise Error instead of a Reply action.

See also:
Transaction handling within OSB

Resources: Helpful Weblogic JMS Links

Creating a JMS Server and Queue in Weblogic:
https://blogs.oracle.com/soaproactive/entry/how_to_create_a_simple

Creating a JMS Error Queue:
http://middlewaremagic.com/weblogic/?p=4670

BPEL - FTP Adapter writes XML file without prefix in the root element

Problem:

When writing a file using the FTP adapter with the message schema defined, for some reason the output would come out without a prefix in the root element, like so:

This would happen even with the XSL transformation declaring the prefix in the root element:



I'm not sure if it's a bug or the fact that we have our schema/transformation wrong, but a coworker and I just couldn't get it to work, so we opted for a workaround using Java embedding.

Solution:

We used the following code to add the prefix to the root element by transforming the XML into a string:

 try{   
   oracle.xml.parser.v2.XMLElement responseFile = (oracle.xml.parser.v2.XMLElement)getVariableData("varResponseFile");   
   //setting prefix to root   
   oracle.xml.parser.v2.XMLNode firstChild = (oracle.xml.parser.v2.XMLNode)responseFile.getFirstChild();   
   responseFile.setPrefix(firstChild.getPrefix());   
   //getting xml document   
   oracle.xml.parser.v2.XMLDocument responseFileXML = (oracle.xml.parser.v2.XMLDocument)responseFile.getDocument();   
   //setting prologue   
   responseFileXML.setVersion("1.0");   
   responseFileXML.setEncoding("UTF-8");   
   //writing xml document   
   java.io.ByteArrayOutputStream outputStream = new java.io.ByteArrayOutputStream();   
   responseFileXML.print(outputStream );   
   String responseFileString = outputStream.toString();   
   //encode xml document   
   oracle.soa.common.util.Base64Encoder encoder = new oracle.soa.common.util.Base64Encoder();   
   String stringEnconded = null;   
   stringEnconded = encoder.encode(responseFileString);   
   //setting xml encoded   
   setVariableData("encodedBody",stringEnconded);   
 } catch (Exception e) {   
   addAuditTrailEntry("Error encoding Response File: " + e.getMessage());   
   throw new RuntimeException(e);   
 }  

We would of course change the FTP message schema to opaque instead. Applying this code would then write the XML file correctly:



If anyone knows how to do this without Java (or perhaps what we are doing wrong in the first place), please let us know in the comments!

DbAdapter - RowSet Column Type Mismatch Error

Problem: 
Invoking an SQL Server stored procedure with the Db Adapter would return the following error:

JCA Binding execute of Reference operation 'dbGetPromotions' failed due to: RowSet Column Type Mismatch Error. The SQL type in the XSD (INT) does not match the SQL type in the RowSet (int identity) for column ReservationID of parameter RowSet0.

This would happen when the DB Adapter would try to return the Output Parameters for the dbGetPromotions operation.

Solution:
Fix the XSD that was generated during the DB Adapter Wizard.

Originally, the XSD had been generated like this:

  <element name="ReservationID" type="int" db:type="INT" minOccurs="0" nillable="true"/>  

However, apparently the db:type needed for the element ReservationID needed to be int identity, so I changed it as follows:

 <element name="ReservationID" type="int" db:type="INT IDENTITY" minOccurs="0" nillable="true"/>  

Usually the same error will tell you what you need to change the db:type to, so just change it accordingly and you're ready to go!

BPEL - Append multiple elements to a list

Problem: I had a list of XML elements like so:

<Messages> <Message Area="RES" Code="Code1"/> <Message Area="RES" Code="Code2"/> <Message Area="RES" Code="Code3"/> </Message>

This is the XSD:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://danytests.com/soa/bpel-append" targetNamespace="http://danytests.com/soa/bpel-append" elementFormDefault="qualified"> <xsd:element name="Messages" type="MessagesType"> <xsd:annotation> <xsd:documentation>A sample element</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:complexType name="MessagesType"> <xsd:sequence> <xsd:element name="Message" maxOccurs="unbounded"> <xsd:complexType> <xsd:attribute name="Area" type="xsd:string"/> <xsd:attribute name="Code" type="xsd:string"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:schema>

What I needed to do was append more items to the already existing list without affecting the ones that were already in there.

At first what I was doing was adding the new items to add to a BPEL variable ($varMessages) that was also of MessagesType. Then, with another variable ($messageCount), I would assign the count of Messages/Message PLUS 1 to it (so, in this case, it would be 4). In a foreach loop, starting with $messageCount, I would do a simple Copy to Messages/Message[$messageCount] and setting the insertMissingToData flag. This, however, isn't really the right way to go about this.

Solution: Use the BPEL Append action instead of the Copy action.

To accomplish this, I would still have the $varMessages variable assigned with the new items to add, but instead my BPEL assign activity would look like this:

<assign name="appendMessages"> <extensionAssignOperation> <bpelx:append> <bpelx:from>$varMessages/ns1:Message</bpelx:from> <bpelx:to>$outputVariable.payload</bpelx:to> </bpelx:append> </extensionAssignOperation> </assign>

That is, I'd assign the Messages from $varMessages to the final list ($outputVariable) in the Messages complexType.

The results were as expected while looking at it in the audit trail. First I'd assign a Message element to the $outputVariable:

Then I'd add elements to $varMessages:

Finally, after the append action, the output variable's final list would look like this:

Neat!