Custom XPATH Function in SOA 11g

This post will explain how to create a custom function and configure in SOA 11g

1. Create a JAVA Class which we need to use it as a custom function.

2. The XSLT processor needs the custom Xpath function to be implemented as Static Java Method with a particular  signature as mentioned below.

public class SOAConstants
{
  public static class SOAConstantsXPathFunction
    implements IXPathFunction
  {
    public Object call(IXPathContext paramIXPathContext, List paramList)
      throws XPathFunctionException
    {
      if ((paramList.size() == 2) && ((paramList.get(0) instanceof String)) && ((paramList.get(1) instanceof String))) {
        try
        {
          String str = getPropertyValue(paramList);
          return str;
        }
        catch (Exception localException)
        {
          System.out.println("The Exception : " + localException);
        }
      }
      throw new XPathFunctionException("Pass Only the Service name  and Constant name to look up");
    }
   
    private static String getPropertyValue(List paramList)
      throws XPathFunctionException
    {
      System.out.println("Inside getPropertyValue");
      String str1 = null;
      try
      {
        Document localDocument = SOAConstantsReader.getInstance().getConstantsAsDoc();
        String str2 = paramList.get(0).toString();
        String str3 = paramList.get(1).toString();
        System.out.println("-- payload :" + str2 + " - " + str3);
        NodeList localNodeList1 = localDocument.getElementsByTagName(str2);
        System.out.println("Got Service NodeList");
        Element localElement = (Element)localNodeList1.item(0);
        System.out.println("Got Service Element" + localNodeList1.item(0).getChildNodes().getLength());
        NodeList localNodeList2 = localElement.getElementsByTagName(paramList.get(1).toString());
        localElement = (Element)localNodeList2.item(0);
        str1 = localElement.getChildNodes().item(0).getNodeValue();
        System.out.println("\nThe value of property: " + str1);
      }
      catch (Exception localException)
      {
        throw new XPathFunctionException("The Exception : " + localException);
      }
      return str1;
    }
  }
}

3. The name of the method can be anything but it must be static and take the given parameters.

4. Implement a  function for XSLT using below format.

public Object call(IXPathContext paramIXPathContext, List paramList)
      throws XPathFunctionException

5. Note the method/Function name must be CALL and non static

6. Compile the code and create a JAR file to implement in Domain folder.

7. Now we need to create a descriptor to describe to SOA Suite and XSLT processor that what custom function we have created.

8. We do this by creating or updating the below file in META-INF directory which will create during the installation of SOA suite.

ext-soa-xpath-functions-config.xml

PATH =  $FMW_HOME/Oracle_SOA1/soa/modules/oracle.soa.ext_11.1.1/classes/META-INF

9. Edit the above file to add the function details

<?xml version = '1.0' encoding = 'UTF-8'?>
<soa-xpath-functions xmlns="http://xmlns.oracle.com/soa/config/xpath"
version="11.1.1" resourceBundle="oracle.tip.tools.ide.common.resource.IDEMessageBundle" xmlns:ora="http://schemas.oracle.com/xpath/extension"
xmlns:vha="http://www.oracle.com/XSL/Transform/java/com.vha.util.action.SOAConstants"
xmlns:vha1="http://www.oracle.com/XSL/Transform/java/com.vha.util.action.SetCompositeInstanceIndex"
xmlns:vhadvm="http://www.oracle.com/XSL/Transform/java/com.vha.util.dvm.CustomDVMLookup"
>
  <function name="vha:getPropertyValue">
    <className>com.vha.util.action.SOAConstants$SOAConstantsXPathFunction</className>
    <return type="string"/>
    <params>
      <param name="parentTagName" type="string"/>
      <param name="childTagName" type="string"/>
    </params>
    <desc resourceKey="GET_PROPERTY VALUE"/>
    <detail>
       <![CDATA[This function will get the value of element from SOAConstants.xml file]]>
    </detail>
  </function>



10. The namespace for the function must be “http://www.oracle.com/XSL/Transform/java/” followed by the full classname of the impementing class.  This is required by the XSLT processor.  The namespace prefix can be anything

11. The function name can be anything but it must have a namespace prefix.


12. Before using the custom function in JDeveloper it needs to be registered.  To do this in JDeveloper we go to the “SOA” section in “Preferences” and add the newly created jar file.  To make JDeveloper see the file we then need to restart JDeveloper.  After doing this we will see the XPath function appears in the “User Defined Extension Functions” in the expression builder.

TCP Dump-Linux/Unix OR SNOOP - Solaris

TCP Dump and  Snoop are built in tools in Unix/Linux and Solaris respectively.

These tools are used to capture the network packets and store it in a file for analysis.

TCP Dump or Snoop can be captured for a particular host of source and store it in a file for further analysis.

The captured dump file will contain source and destination address, state and flag information set in the header.

By default tcp dump will capture first 96 bytes of the capture and we can modify the command to capture complete information of the packets.

TCP Dump or Snoop file can be analyzed using wire-shark tool .

commands used to capture the dumps are

tcpdump -w filename.pcap -s0 -i -n src host IPAddress

snoop -i IP

Solaris Memory Utilization

Solaris servers uses certain percentage of free memory for IO cache.

This is based on the ZFS configuration.  This configuration can be checked using root or kernel access.

If there is no memory available, then these cache memory will be used.

If the Application need memory, the I/O cache will release the memory.

The "sr" value on vmstat provide the status of the Memory swap rate.

As long as the "sr" value stays at zero there is no memory issue. 

HTTP - Access Log Entries

c-ip date time cs-method cs-uri cs-status bytes time-taken

Weblogic DataSource

Data Source Connection Pool Sizing

By Steve Felts on Dec 10, 2012

One of the most time-consuming procedures of a database application is establishing a connection. The connection pooling of the data source can be used to minimize this overhead.  That argues for using the data source instead of accessing the database driver directly.

Configuring the size of the pool in the data source is somewhere between an art and science – this article will try to move it closer to science. 

From the beginning, WLS data source has had an initial capacity and a maximum capacity configuration values.  When the system starts up and when it shrinks, initial capacity is used.  The pool can grow to maximum capacity.  Customers found that they might want to set the initial capacity to 0 (more on that later) but didn’t want the pool to shrink to 0.  In WLS 10.3.6, we added minimum capacity to specify the lower limit to which a pool will shrink.  If minimum capacity is not set, it defaults to the initial capacity for upward compatibility.   We also did some work on the shrinking in release 10.3.4 to reduce thrashing; the algorithm that used to shrink to the maximum of the currently used connections or the initial capacity (basically the unused connections were all released) was changed to shrink by half of the unused connections.

The simple approach to sizing the pool is to set the initial/minimum capacity to the maximum capacity.  Doing this creates all connections at startup, avoiding creating connections on demand and the pool is stable.  However, there are a number of reasons not to take this simple approach.

When WLS is booted, the deployment of the data source includes synchronously creating the connections.  The more connections that are configured in initial capacity, the longer the boot time for WLS (there have been several projects for parallel boot in WLS but none that are available).  Related to creating a lot of connections at boot time is the problem of logon storms (the database gets too much work at one time).   WLS has a solution for that by setting the login delay seconds on the pool but that also increases the boot time.

There are a number of cases where it is desirable to set the initial capacity to 0.  By doing that, the overhead of creating connections is deferred out of the boot and the database doesn’t need to be available.  An application may not want WLS to automatically connect to the database until it is actually needed, such as for some code/warm failover configurations.

There are a number of cases where minimum capacity should be less than maximum capacity.  Connections are generally expensive to keep around.  They cause state to be kept on both the client and the server, and the state on the backend may be heavy (for example, a process).  Depending on the vendor, connection usage may cost money.  If work load is not constant, then database connections can be freed up by shrinking the pool when connections are not in use.  When using Active GridLink, connections can be created as needed according to runtime load balancing (RLB) percentages instead of by connection load balancing (CLB) during data source deployment.

Shrinking is an effective technique for clearing the pool when connections are not in use.  In addition to the obvious reason that there times where the workload is lighter,  there are some configurations where the database and/or firewall conspire to make long-unused or too-old connections no longer viable.  There are also some data source features where the connection has state and cannot be used again unless the state matches the request.  Examples of this are identity based pooling where the connection has a particular owner and XA affinity where the connection is associated with a particular RAC node.  At this point, WLS does not re-purpose (discard/replace) connections and shrinking is a way to get rid of the unused existing connection and get a new one with the correct state when needed.

So far, the discussion has focused on the relationship of initial, minimum, and maximum capacity.  Computing the maximum size requires some knowledge about the application and the current number of simultaneously active users, web sessions, batch programs, or whatever access patterns are common.  The applications should be written to only reserve and close connections as needed but multiple statements, if needed, should be done in one reservation (don’t get/close more often than necessary).  This means that the size of the pool is likely to be significantly smaller then the number of users.  

If possible, you can pick a size and see how it performs under simulated or real load.  There is a high-water mark statistic (ActiveConnectionsHighCount) that tracks the maximum connections concurrently used.  In general, you want the size to be big enough so that you never run out of connections but no bigger.   It will need to deal with spikes in usage, which is where shrinking after the spike is important.  Of course, the database capacity also has a big influence on the decision since it’s important not to overload the database machine.  Planning also needs to happen if you are running in a Multi-Data Source or Active GridLink configuration and expect that the remaining nodes will take over the connections when one of the nodes in the cluster goes down.  For XA affinity, additional headroom is also recommended.  

In summary, setting initial and maximum capacity to be the same may be simple but there are many other factors that may be important in making the decision about sizing.

Weblogic JMS Queue

1. A JMS queue in Weblogic Server is associated with a number of additional resources:

JMS Server

A JMS server acts as a management container for resources within JMS modules. Some of its responsibilities include the maintenance of persistence and state of messages and subscribers. A JMS server is required in order to create a JMS module.

JMS Module

A JMS module is a definition which contains JMS resources such as queues and topics. A JMS module is required in order to create a JMS queue.

Subdeployment

JMS modules are targeted to one or more WLS instances or a cluster. Resources within a JMS module, such as queues and topics are also targeted to a JMS server or WLS server instances. A subdeployment is a grouping of targets. It is also known as advanced targeting.

Connection Factory

A connection factory is a resource that enables JMS clients to create connections to JMS destinations.

JMS Queue

A JMS queue (as opposed to a JMS topic) is a point-to-point destination type. A message is written to a specific queue or received from a specific queue.

2. The following steps are done in the WebLogic Server Console, beginning with the left-hand navigation menu.

2.1 Create a JMS Server

1. Services > Messaging > JMS Servers
   
   
2. Select New
3. Name: TestJMSServer
   Persistent Store: (none)
4. Target: soa_server1  (or choose an available server)
5. Finish

The JMS server should now be visible in the list with Health OK.

2.2 Create a JMS Module

1. Services > Messaging > JMS Modules
2. Select New
3. Name: TestJMSModule
   Leave the other options empty
4. Targets: soa_server1  (or choose the same one as the JMS server) or Cluster
   Press Next
5. Leave “Would you like to add resources to this JMS system module” unchecked and  press Finish .

2.3 Create a SubDeployment

A subdeployment is not necessary for the JMS queue to work, but it allows you to easily target subcomponents of the JMS module to a single target or group of targets. We will use the subdeployment in this example to target the following connection factory and JMS queue to the JMS server we created earlier.

1. Services > Messaging > JMS Modules
2. Select TestJMSModule
3. Select the Subdeployments  tab and New
4. Subdeployment Name: TestSubdeployment
5. Press Next
6. Here you can select the target(s) for the subdeployment. You can choose either Servers (i.e. WebLogic managed servers, such as the soa_server1) or JMS Servers such as the JMS Server created earlier. As the purpose of our subdeployment in this example is to target a specific JMS server, we will choose the JMS Server option.
   Select the TestJMSServer created earlier
7. Press Finish

2.4  Create a Connection Factory

1. Services > Messaging > JMS Modules
2. Select TestJMSModule  and press New
3. Select Connection Factory  and Next
4. Name: TestConnectionFactory
   JNDI Name: jms/TestConnectionFactory
   Leave the other values at default
5. On the Targets page, select the Advanced Targeting  button and select TestSubdeployment
6. Press Finish

The connection factory should be listed on the following page with TestSubdeployment and TestJMSServer as the target.

2.5 Create a JMS Queue

1. Services > Messaging > JMS Modules
2. Select TestJMSModule  and press New
3. Select Queue and Next
4. Name: TestJMSQueue
   JNDI Name: jms/TestJMSQueue
   Template: None
   Press Next
5. Subdeployments: TestSubdeployment
6. Finish

The TestJMSQueue should be listed on the following page with TestSubdeployment and TestJMSServer.

Confirm the resources for the TestJMSModule. Using the Domain Structure tree, navigate to soa_domain > Services > Messaging > JMS Modules then select TestJMSModule

You should see the following resources

The JMS queue is now complete and can be accessed using the JNDI names

jms/TestConnectionFactory and
jms/TestJMSQueue

XA and Non XA DataSource

An XA transaction, in the most general terms, is a "global transaction" that may span multiple resources. A non-XA transaction always involves just one resource. 

An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions). 

XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form. 

Most stuff in the world is non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database. XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources. Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are commited across all of the resources. When you say "rollback", _everything_ is rolled back across all resources. 

The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources. 

In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can't participate in a global transaction (sort of - some people implement what's called a "last participant" optimization that can let you do this for exactly one non-XA item). 

For more details - see the JTA pages on java.sun.com. Look at the XAResource and Xid interfaces in JTA. See the X/Open XA Distributed Transaction specification. Do a google source on "Java JTA XA transaction".