getting started with custom commands in WLST @SOASuite11g

I was recently having a requirement to use WebLogic Scripting Tool because it gave a lot of flexibility to configure SOA composite applications. In WLST there was OFFLINE option for doing deployments and for Composite Application Management.

You can get  wlst commands  @ here

Some of the commands which I loved using are

1.    sca_deployComposite : Deploy a SOA composite application.

2.    sca_undeployComposite : Un deploy a SOA composite application.

3.    sca_startComposite : Start a previously stopped SOA composite application.

4.    sca_stopComposite :Stop a SOA composite application.

5.    sca_activateComposite : Activate a previously retired SOA composite application.

6.    sca_retireComposite : Retire a SOA composite application.

7.    sca_listDeployedComposites : List the deployed SOA composite applications.

Oracle SOA Suite, MDS, and services such as SSL and logging, supply custom WLST commands.

To use those custom commands, you must invoke the WLST script from the Oracle home. Do not use the WLST script in the WebLogic Server home.

The script is located at:

(UNIX) MIDDLEWARE_HOME/ORACLE_SOA1/common/bin/wlst.sh

(Windows) MIDDLEWARE_HOME\Oracle_SOA1\common\bin\wlst.cmd

In case you use the WLS tool from

 MIDDLEWARE_HOME\oracle_common\common\bin

Or  from

MIDDLEWARE_HOME \wlserver_10.3\common\bin

It will throw following error.

Traceback (innermost last):

  File "", 1,="" ?<="" in="" line="" span="">",>

NameError: sca_undeployComposite

To show the way, I will use  sca_undeployComposite command. For un-deploying composite processes using wlst while the soa-infra is offline use the following custom command.

>>  sca_undeployComposite

Syntax

sca_undeployComposite(serverURL, compositeName, revision, user, password)

Argument	Definition
serverURL	URL of the server that hosts the SOA Infrastructure application (for example, http://localhost:8001).
compositeName	Name of the SOA composite application.
Revision	Revision ID of the SOA composite application.
User	Optional. User name to access the composite deployer servlet when basic authentication is configured.
Password	Optional. Password to access the composite deployer servlet when basic authentication is configured.

How to use it

(UNIX) ORACLE_HOME/common/bin/wlst.sh

(Windows) ORACLE_HOME\common\bin\wlst.cmd

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> connect()

Please enter your username [weblogic] :weblogic

Please enter your password [welcome1] :

Please enter your server URL [t3://localhost:7001] : t3://localhost:7001

Connecting to t3://localhost:7001 with userid weblogic ...

Successfully connected to Admin Server 'AdminServer' that belongs to domain 'soa_domain'.

wls:/soa_domain/serverConfig> sca_undeployComposite("http://localhost:8001","GeoComposite", "1.0","weblogic","weblogic123")

serverURL = http://localhost:8001

user = weblogic

partition = default

compositeName = GeoComposite

revision = 1.0

timeout= -1

set user and password...

compositeDN = default/GeoComposite!1.0

Creating HTTP connection to host:localhost, port:8001

Received HTTP response from the server, response code=200

---->Undeploying composite (default/GeoComposite!1.0) success.

That’s pretty much for the day. Happy Easter and a long weekend

Compilation issue with MDS repository

Recently while migrating the code from DEV to Test environment, customer had issues with respect to MDS repository. Since the customer was using MDS for the first time there were many queries on how the migration will work, the amount of work involved in the process of migration. They had used MDS store as the common repository for all the artifacts (DVM,XSD’s,XRef). The different processes refer these artifacts from MDS.

The build scripts are being used for the compilation /deployment of processes to the Server. During compilation build script looks up adf-config.xml to get the MDS store connection details. Everything works fine when customer uses connection string/username/pwd in adf-config.xml.

As a pre-requisite for migrating codebase, all the shared artifacts@ MDS were migrated to the new environment. So for compilation, the team was planning to use the new environment MDS details, but customer was not willing to expose the MDS store credentials in different process files.

These are some approaches that we tried out for resolving the issue and completing the deployment to the new environment.

1.    First approach was to mention jndi-datasource as mentioned in release notes  @ http://download.oracle.com/docs/cd/E17904_01/relnotes.1111/e10133/soa.htm

If the MDS database has a JNDI name, then use the following entries in adf-config.xml:

<metadata-store

  class-name="oracle.mds.persistence.stores.db.DBMetadataStore">

     <property name="jndi-datasource" value="${db.jndi.name}"/>

     <property name="partition-name" value="soa-infra"/>

Here db.jndi.name = jdbc/mds/MDS_LocalTxDataSource , the JNDI name of mds-soa datasource.

But this did not work out as the build scripts were not able to look up the JNDI from the server.

The error stacktrace while compiling the process.

     [scac]     at oracle.adf.share.config.ADFContextMDSConfigHelperImpl.createMDSSession(ADFContextMDSConfigHelperImpl.java:50)

     [scac]     ... 26 more

     [scac] Caused by: oracle.mds.config.MDSConfigurationException: MDS-01330: unable to load MDS configuration document

     [scac] MDS-01329: unable to load element "persistence-config"

     [scac] MDS-01370: MetadataStore configuration for metadata-store-usage "mstore-usage_2" is invalid.

     [scac] MDS-00922: The ConnectionManager "oracle.mds.internal.persistence.db.JNDIConnectionManagerImpl" cannot be instantiated.

     [scac] MDS-00929: unable to look up name "jdbc/mds/MDS_LocalTxDataSource" in JNDI context

     [scac] Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial

This approach was a failure. Not yet fully incorporated into 11g build scripts.

         

2.       Use any file based repository and complete the deployment. The Compilation process will look up the adf-config.xml for using the MDS store details to validate the XSD’s referred in the process. Place all the XSD’s referred by the process in a machine and specify the path in metadata-path.

          File –based repository can be referred in adf-config.xml as below.

            <metadata-store class-name="oracle.mds.persistence.stores.file.FileMetadataStore">

              <property value="/GEO_BUILD/mdsutil"  name="metadata-path"/>

              <property value="seed" name="partition-name"/>

3.       Use any dev MDS repository connection details and complete the deployment. The Compilation process will look up the adf-config.xml for using the MDS store details to validate the XSD’s referred in the process.

            <metadata-store class-name="oracle.mds.persistence.stores.db.DBMetadataStore">

              <property value="DEV_MDS" name="jdbc-userid"/>

              <property value="password" name="jdbc-password"/>

              <property value="jdbc:oracle:thin:@//localhost:1522/GEODB"

                        name="jdbc-url"/>

              <property value="soa-infra" name="partition-name"/>

            </metadata-store>

This 2 & 3 approaches will work fine because the adf-config.xml details are used only during compilation /validation. At runtime the BPEL engine will refer the artifacts directly from MDS store configured in the environment.

Hope this helps.

Overloaded Health State @ weblogic server

One of the issues which I recently faced for a client was with regard to Weblogic Server running on Overload status. It was sort of surprising to see a new health status in the server console other than Ok /Running .

Issue

It was pretty clear that the issue was related with Connection Pool usage.

There were clear pointers in log files also.

Internal error: Cannot obtain XAConnection weblogic.common.resourcepool.ResourceLimitException: No resources currently available in pool AppsAQ to allocate to applications, please increase the size of the pool and retry..[[

        at weblogic.common.resourcepool.ResourcePoolImpl.reserveResourceInternal(ResourcePoolImpl.java:555)

        at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:332)

        at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:438)

        at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:93)

For troubleshooting the issue, we started monitoring the connection pool usage.

Analysis and Resolution

 As part of design we have an Apps queue which will be queuing up all the messages for outbound flow. Of late the number of processes listening to the queue had gone up, and all were trying to establish connections with the queue and de-queue the messages based on correlation ids. The number of connections in connection pool was set at 15 by default and the number of connection to the queue was more than 20 which resulted in the overloaded state. So by increasing the number of connections to the Apps queue we were able to resolve the issue.

More on Overloaded Health State

WebLogic Server 9.0 has a new health state—OVERLOADED—which is returned by the ServerRuntimeMBean.getHealthState() when a server instance whose life cycle state is RUNNING becomes overloaded. This condition occurs when Work Manager capacity is exceeded or as a result of low memory. 

The server instances health state returns to OK after the overload condition passes. An administrator can suspend or shut down an OVERLOADED server instance. 

more on Callout feature @B2B

Callout is one of the features given in B2B to achieve custom functionality which is not supported out of the box by Oracle B2B.The custom functionality can be written in java where you will get access to the payload and can be worked upon based on the requirements.

There are two ways in which we can use the callout.

1. Transport Callouts
2.  Agreement Callouts

In this blog I will touch upon some of the major differences/similarities between these 2 callouts.

Transport Callout

1.  Configure a Channel at Host or trading partner level, depending on whether the document flow is Inbound and outbound.
2. Select the java callout for Transport callout attribute under Channel Attributes.

·         For the inbound message, B2B invokes the transport callout immediately after it receives a message from the transport.

·         For the outbound message, B2B invokes the transport callout immediately before it sends a message to the transport.

3. When you call it from Transport level, java callout will get following metadata information as message parameters to the java callout along with message payload.

Filename , callout.class, DATE, callout.timeout, file.sender.type, callout.library,

TO, callout.param.BASE_LOCATION, callout.name, FROM, MESSAGE-ID

Eg sample data:

filename=Geo_2011Feb23_06_20_02_014_308_284.dat

callout.class=com.geo.b2b.callout.ArchiverTest

DATE=Wed, 23 Feb 2011 11:20:01 GMT

callout.timeout=30

file.sender.type=BINARY

callout.library=TestCallout.jar

TO=OracleINC

callout.param.BASE_LOCATION= /tmp/ARCHIVE

callout.name=TestCallout

FROM=Geo

MESSAGE-ID=34323438343736363736353

Agreement Callout

In case we decide to go callout at Agreement level,

1. Create an agreement at partner level
2. While defining callout, we will declare all the callout parameters that need to be passed to the Callout function. These values can be modified while defining the callout at agreement level for each TP.

points to note:

1. In the case of Agreement level callout, the transport level metadata information will not be available to the java callout. In case we require similar information these will have to be first configured as parameters while defining a callout and these values will have to be passed as callout parameters while defining the agreement.
2. In case of a outbound flow, when we are archiving a file from transport level using a callout will store the payload as a Edi document where as the payload archived at agreement level will be in XML format. So in case the business requirement is to archive EDI format documents, then always use Transport level callouts.(This is applicable in cases we are not using the out-of the box archiving feature.)
3. Transport callout takes precedence over Agreement callout, and so in case we enable the same callout at both levels, and try to update parameters of callout, parameter value updating at agreement level will not affect the callout behavior.
4. Use DiagnosticService for logging audit information (explained in one of my previous blogs) which will help you in debugging.

Hope this helps. J