Wednesday Mar 27, 2013

B2B Agreement Life-Cycle Management, Part 2 - Best Practices for High Volume Deployment of Agreements


In Part 1 of the B2B Agreement Life-Cycle Management Series, we looked at the best practices to import high volume of agreement metadata into the repository [1]. In this post, we will take a look at the best practices to deploy the agreement metadata for run-time processing.


B2B 11g supports the notion of agreements, which serve as the binding contract between different partners and documents defined within the repository. In order to facilitate run-time processing of messages, these agreements must be deployed so that the corresponding metadata can be queried for runtime validation of message content.

In production systems with large B2B repository containing several partners, documents and agreements, the system performance could be severely affected, if the deployment of the agreements is not managed properly.

This note highlights the best practices for deployment of agreements, when large numbers of partners and documents in the excess of several hundreds are required to be maintained within the B2B repository.


The run-time processing of inbound messages, typically go through a validation phase, where the message contents are tested against the metadata pre-defined for the particular document.

Usually these operations complete fairly quickly. However, as the number of deployed agreements within the repository goes up to several hundreds and beyond, the time to complete internal processing by the engine could go up by a significant amount. If that happens, it may be worth looking into the state of the MDS labels active within the repository.


Bulk Deploy

All the agreements created for all trading partners and all document definitions within the B2B repository, can be deployed by a single invoke of the ant utility for B2B deploy. This would ensure that only 1 active label is created for all the agreements created. Thus, the number of labels within MDS will be at a minimum and not add aditional processing overhead on the system perfromance when labels need to be referred to at runtime for metedata retrieval.

Multi-Agreement Deploy

In certain situations, the operating constraints on a production system, may limit the possibility of carrying out a bulk deploy, as mentioned previously. In that case, it might still be helpful to deploy multiple agreements in batches. The greater the batch sizes are, the less will be the performance overhead, since they will reduce the number of active MDS labels in turn. The key objective here is to minimize the number of active MDS labels as much as possible.


Let us take a look at the numbers of active MDS labels created as a result of our 2 types of agreement deployment operations.The examples cited here use the command-line utilities that are available as part of the B2B 11g install. These operations can also be performed via the B2B console, after selecting multiple agreements for deployment. However, for production systems, it is always recommended to develop custom scripts based on the command-line utilities available.

In the first case, we are deploying the 2 agreements were individually deployed one at a time.

  • ant -f ant-b2b-util.xml b2bdeploy -Dtpanames="MarketInc_OracleServices_X12_4010_850_Agr_In" 
  • ant -f ant-b2b-util.xml b2bdeploy -Dtpanames="MarketInc_OracleServices_X12_4010_997_Agr_Out"

When we investigate the B2B_LIFECYCLE table, we see that there were 2 MDS labels created for each deployment of 2 agreements. It should also be noticed that both of these agreements and labels are in active state.

SQL> select state, count(*), count(distinct label)

from b2b_lifecycle
group by state

---------------   ---------------- ------------------------------------------
Active                           2                                         2


Alternatively, when both of these agreements were deployed together, only 1 active MDS label was created for both the active agreements. 

  • ant -f ant-b2b-util.xml b2bdeploy -Dtpanames="MarketInc_OracleServices_X12_4010_850_Agr_In,MarketInc_OracleServices_X12_4010_997_Agr_Out"

 SQL> select state, count(*), count(distinct label)

from b2b_lifecycle
group by state

---------------    ---------------- ------------------------------------------
Active                           2                                         1


The basic syntax for bulk deploy is the same as shown earlier, without any agreement names in the command-line. e.g.

  • ant -f ant-b2b-util.xml b2bdeploy

For few agreements, the bulk deployment can also be achieved via the B2B console UI, by selecting all the agreements before clicking for deployment. However, in general, UI is not recommended for deployment. Scripts using the command-line utilities should be developed for deployment of agreements as a best practice.

After the deployment is completed, all the existing active agreements and labels will go into an inactive state. A standard maintenance procedure should be implemented to purge all the inactive agreements and labels for proper housekeeping.


The key objective is to minimize the number of active MDS labels generated as a result of deployment of agreements for run-time processing. Ideally, a bulk deploy would result in 1 active MDS label for the entire repository.

In situations where bulk deploy is not possible, minimizing the number of active MDS labels should be a top priority. So, techniques like deployment of several agreements in a comma-separated list via one command-line invoke should be used in non-ideal situations, whenever possible.


The material posted here has been compiled with the help from B2B Engineering and Product Management teams.


1. B2B Agreement Life-Cycle Mgmt Part 1 - Best Practices for High Volume Import of CPA Metadata into B2B Repository.

Thursday Aug 11, 2011

Full access to MDS Repository

JDeveloper allows you to browse the tree structure of any MDS repository, DB or File based. After creating the appropriate connection, a JTree is created, and all documents and packages of the MDS repository are available in it. To manipulate those documents, it is not unusual to use WLST (WebLogic Scripting Tool). MDS provides a few APIs for now, obviously dedicated to the manipulation of the documents needed and managed by the SOA/SCA part of the stack. MDS can definitely be used to store any sharable document, whether they are related to SCA or not. Currently this manipulation of the MDS artifacts using WLST is not supported in 11g, however in this blog post we are sharing a way to access those documents from the command line scripting tool. The approach we took was to use the tools JDeveloper is using to build the MDS Connection tree. The linked archive provides a JDeveloper project that contains one class, named MDSUtils. It requires a couple of libraries to be used at compilation and runtime (mentioned in the project available at the bottom of the post). This class contains a main method, illustrating the way to use it from Java.
   public static void main(String[] args)
       MDSInstance mdsInstance = null;
       mdsInstance = MDSUtils.initializeDBStore("TEST_MDS",
       // Recurse and display, from the root.
       recurse(mdsInstance, null, 0);

       // Find a resource
       List list = MDSUtils.findResource(mdsInstance, "deployed-composites", false);
       System.out.println("List: (" + list.size() + " element(s))");
       for (ResourceName rn : list)
         System.out.println("Found : " + rn.getAbsoluteName() + " (a " + 
                            (rn.isPackageName()?"package":"document") + ")");

       MDSUtils.createFolder(mdsInstance, PackageName.createPackageName("/oliv"));

       // Deleting folder
       List list = MDSUtils.findResource(mdsInstance, "oliv", false);
       System.out.println("List: (" + list.size() + " element(s))");
       for (ResourceName rn : list)
         System.out.println("Found : " + rn.getAbsoluteName() + " (a " + 
                                  (rn.isPackageName()?"package":"document") + ")");
         if (rn.isPackageName() && rn.getAbsoluteName().equals("/oliv"))
           System.out.println("Deleting " + rn.getAbsoluteName());
           MDSUtils.deleteResource(mdsInstance, rn);
           System.out.println("Leaving " + rn.getAbsoluteName() + " alone.");
As WLST is based on Jython, and as Jython can make Java calls, the bridge between WLST and the Java code above is obvious. Here is a code snippet doing the something close to the Java code above, that can be run using WLST:
print "-----------------------------"
y = "Yes"
Y = y
n = "No"
N = n
from oracle.ateam import MDSUtils
mdsUtils = MDSUtils()
# setup Connection parameters
# The first call (createFolder, deleteFolder) will create the 
MDSInstance with those parameters.
response = input("Do we create the \"oliv\" directory ? [y|n] > ")
if response == y:
   print "Creating directory"
response = input("Do we delete the \"oliv\" directory ? [y|n] > ")
if response == y:
   print "Deleting directory"
print "Done."
print "Bye now"

The only thing to do before running this snippet from WLST is to put the required classes in WLST's classpath. A script contained in the archive is illustrating this point.

The JDeveloper project containing the code is available from here.


This is the blog for the Oracle FMW Architects team fondly known as the A-Team. The A-Team is the central, technical, outbound team as part of the FMW Development organization working with Oracle's largest and most important customers. We support Oracle Sales, Consulting and Support when deep technical and architectural help is needed from Oracle Development.
Primarily this blog is tailored for SOA issues (BPEL, OSB, BPM, Adapters, CEP, B2B, JCAP)that are encountered by our team. Expect real solutions to customer problems, encountered during customer engagements.
We will highlight best practices, workarounds, architectural discussions, and discuss topics that are relevant in the SOA technical space today.


« July 2016