Friday, January 30, 2009

ESB internal topics

One of the queries I used to get in ESB was on the role of different JMS topics used in ESB.

I am listing down the main topics used in ESB.


There are 2 parts of the ESB engine - ESB designtime server & ESB runtime server

The ESB designtime server (ESBDT) provides interfaces for all metadata changes from JDeveloper, ant-based import/export or browser-based ESB Control changes.

The ESB runtime server (ESBRT) loads an in-memory cache at startup that contains all service metadata and artifacts such that services run straight from memory.

Async Topic - used for storage of messages that are delivered asynchronously.

Error Topic - will have the messages that could not be delivered due to an error.

Monitor Topic – ESBDT subscribes to this topic to get tracking messages from ESBRT

Control Topic ESB runtime servers listen on the control topic to get notified of any metadata changes

Resub Topic – This topic stores the payload for esb instances where retryable error has occured.

The primary mechanism of interaction between ESBDT and the ESBRT nodes is through

JMS topics. The ESBDT subscribes to both a monitor and error topic to which all ESBRT instances publish their monitoring and error messages. ESBDT then persists that information to the database. The ESBDT also publishes administration messages to a control topic to which all ESBRT instances subscribe.

thats it for today cheers :)


Monday, January 5, 2009

XSL Development issues using Jdeveloper

I am listing down some development issues that developers may face while using XSL transformations

Issue #1

In some cases the values from the routing service with OAGIS specific xsd are not getting transferred to another Routing service/BPEL even after mapping all the records using Jdev XSL auto map tool.

Reason

The XSLT map tool of JDEV has a bug where one of the nodes is used without the namespace prefix.

Solution

Do all the required mapping using the XSLT mapper of JDEV. Do required mapping. Cross check couple of times that all nodes are mapped properly. Then go to source add the required namespace-prefix to all the nodes prefix is missing.

For example an OAGIS schema BOD has an ApplicationArea and DataArea .When you map the values from one OAG routing service to another the Jdev tool misses out on adding namespace prefix to DataArea. So always check whether the prefix exists for all the elements. Once you add the namespace-prefixes, the design tab will not work, so always finish all the mappings then only add the namespace-prefix. Given below is the code-snippet which jdev is generating and correct one after modifying the XSL. ApplicationArea values were coming properly because it has proper namespace-prefix. DataArea has no namespace-prefix. So values are not populated.

JDEv XSLT

<ns10:ApplicationArea>

……………

…………………..

</ns10:ApplicationArea>

<DataArea>

<ns10:Get>

<xsl:attribute name="uniqueIndicator">

<xsl:value-of select="/imp1:GetPlanningSchedule/DataArea/imp1:Get/@uniqueIndicator"/>

</xsl:attribute>

……………………..

…………………………

</ns10:Get>

<xsl:for-each select="/imp1:GetPlanningSchedule/DataArea/imp1:PlanningSchedule">

…………………………….

Correct XSLT

<ns10:ApplicationArea>

……………

…………………..

</ns10:ApplicationArea>

<ns10:DataArea>

<ns10:Get>

<xsl:attribute name="uniqueIndicator">

<xsl:value-of select="/imp1:GetPlanningSchedule/imp1:DataArea/imp1:Get/@uniqueIndicator"/>

</xsl:attribute>

…………………………………………..

……………………………………..

</ns10:Get>

<xsl:for-each select="/imp1:GetPlanningSchedule/imp1:DataArea/imp1:PlanningSchedule">

Issue #2

Sometimes the changes made to the existing XSL are not reflecting in the ESB.

Reason

The metadata server/runtime server cache is not getting updated properly. This is a bug

Solution

If you making changes try to use a new mapping file(XSL) everytime. (risk free)Then copy the content from old xsl to the new one and then add new changes required to the XSL.