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

Introduction

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.

Background

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.

Symptoms

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.

Remedy

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.

Results

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
/

STATE             COUNT(*) COUNT(DISTINCTLABEL)
---------------   ---------------- ------------------------------------------
Active                           2                                         2

SQL>


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
/

STATE             COUNT(*) COUNT(DISTINCTLABEL)
---------------    ---------------- ------------------------------------------
Active                           2                                         1

SQL>


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.

Summary

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.

Acknowledgements

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

References

1. B2B Agreement Life-Cycle Mgmt Part 1 - Best Practices for High Volume Import of CPA Metadata into B2B Repository. https://blogs.oracle.com/ateamsoab2b/entry/best_practices_for_high_volume

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About


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.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today