Wednesday Mar 27, 2013

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

Tuesday Jan 29, 2013

SOA Suite for Healthcare Integration startup errors due to expired passwords.

Background

SOA Suite for Healthcare integration involves starting up the managed servers, which are in turn, dependent on valid connections to databases. In many low-maintenance environment like Virtualbox images distributed for training and workshops, the database passwords are likely to expire after a certain period. Subsequently, the related SOA startup error becomes a road-block for users not familiar with the database dependencies.

This note describes the step-by-step instructions to resolve the password expiry errors and get the SOA Suite for Healthcare Integration environment back up and running.

Symptoms

The errors seen on startup of SOA server could look like the following:

  • Caused by: javax.ejb.CreateException: SDP-25700: An unexpected exception was caught.
  • Cause: weblogic.common.resourcepool.ResourceDeadException:
  • weblogic.common.ResourceException: Could not create pool connection.
  • The DBMS driver exception was: ORA-28001: the password has expired

Remedy

The error is caused by the fact that the database passwords in the image are set to expire after a definite period. To get past the issue, the passwords for the following database users have to be reset:

  • DEV_SOAINFRA
  • DEV_MDS
  • DEV_ORASDPM

These users with DEV_ prefix are the default but could vary in other situations, where custom prefixes may have been used during installation of SOA Suite repository. 

All the passwords can be set to the original value, e.g. welcome1 by logging into a SQL*PLus session as a DBA and using the following command for each database user one at a time :

  • SQL> Alter user <username from above list> identified by welcome1;
The above procedure is applicable to all database users. Alternatively, upon attempts to login to a SQL*Plus session as a database user with expired password, the session itself can prompt for new passwords.

Results

Below, we have the excerpt from a terminal session captured from the Virtualbox image, distributed for SOA Suite for Healthcare Integration training. It shows how the passwords were reset using the approaches mentioned earlier.


[oracle@soahc ~]$ . oraenv
ORACLE_SID = [orcl] ?
The Oracle base for ORACLE_HOME=/u01/DBInstall/product/11.2.0/dbhome_1 is /u01/DBInstall
[oracle@soahc ~]$ sqlplus

SQL*Plus: Release 11.2.0.1.0 Production on Date...

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Enter user-name: system
Enter password: welcome1
ERROR:
ORA-28001: the password has expired


Changing password for system
New password: welcome1
Retype new password: welcome1
Password changed

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter user DEV_SOAINFRA identified by welcome1;

User altered.

SQL> alter user DEV_MDS identified by welcome1;

User altered.

SQL> alter user DEV_ORASDPM identified by welcome1;

User altered.

SQL> conn / as sysdba
Connected.

SQL>


Wednesday Jan 16, 2013

Oracle SOA for Healthcare - Setting Endpoint Acknowledgement Acceptance

Acknowledgment acceptance in SOA Suite for Healthcare is globally set through the console at the document level. Currently there is no way to override the global setting for an endpoint in the SOA for Healthcare console. The illustration below shows acknowledgment acceptance being set in the document type definition in the SOA for Healthcare console

[Read More]

Friday Dec 21, 2012

Oracle B2B – b2b.rowLockingForCorrelation

In cases where the latency between the outbound EDI document and the subsequent inbound acknowledgment is very low, a race condition will likely occur when B2B tries to update the document state in the B2B_BUSINESS_MESSAGE table. The result is the status of the original EDI document remains in either a MSG_WAIT_FA or MSG_WAIT_ACK state indefinitely if no retry value has been set, or it evolves to a state of MSG_ERROR after the retry interval and all the retry attempts have expired.[Read More]

Saturday Dec 15, 2012

B2B Agreement Life-Cycle Management, Part 1 - Best Practices for High Volume CPA Import Operations with ebXML

Introduction

This is Part 1 of the B2B Life-Cycle Management Series. The series will discuss the best practices around various aspects of the complete B2B agreement life cycle. This post will discuss the first part which is related to the import of data artifacts into the repository. The specific use case discussed here is for CPAs related to ebXML data but the concepts are fairly generic and the process can be extended to any document or protocol.

Background

B2B 11g supports ebXML messaging protocol, where multiple CPAs can be imported via command-line utilities. 

This note highlights one aspect of the best practices for import of CPA, when large numbers of CPAs in the excess of several hundreds are required to be maintained within the B2B repository.

Symptoms

The import of CPA usually is a 2-step process, namely creating a soa.zip file using b2bcpaimport utility based on a CPA properties file and then using b2bimport to import the b2b repository.  The commands are provided below:

  1. ant -f ant-b2b-util.xml b2bcpaimport -Dpropfile="<Path to cpp_cpa.properties>" -Dstandard=true
  2. ant -f ant-b2b-util.xml b2bimport -Dlocalfile=true -Dexportfile="<Path to soa.zip>" -Doverwrite=true

Usually the first command completes fairly quickly regardless of the number of CPAs in the repository. However, as the number of trading partners within the repository goes up, the time to complete the second command could go up to ~30 secs per operation. So, this could add up to a significant amount, if there is a need to import hundreds of CPA in a production system within a limited downtime, maintenance window. 

Remedy

In situations, where there is a large number of entries to be imported, it is best to setup a staging environment and go through the import operation of each individual CPA in an empty repository. Since, this will be done in an empty repository, the time taken for completion should be reasonable. 

After all the partner profiles have been imported, a full repository export can be taken to capture the metadata for all the entries in one file. 

If this single file with all the partner entries is imported in a loaded repository, the total time taken for import of all the CPAs should see a dramatic reduction.

Results

Let us take a look at the numbers to see the benefit of this approach. With a pre-loaded repository of ~400 partners, the individual import time for each entry takes ~30 secs. So, if we had to import another 100 partners, the individual entries will take ~50 minutes (100 times ~30 secs). On the other hand, if we prepare the repository export file of the same 100 partners from a staging environment earlier, the import takes about ~5 mins.

The total processing time for the loading of metadata, specially in a production environment, can thus be shortened by almost a factor of 10.

Summary

The following diagram summarizes the entire approach and process.

Acknowledgements

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

Monday Dec 10, 2012

Oracle B2B - Synchronous Request Reply

Beginning with Oracle SOA Suite PS5 (11.1.1.6), B2B supports synchronous request reply over http using the b2b/syncreceiver servlet. I’m attaching a demo to this blog which includes a SOA composite archive that needs to be deployed using JDeveloper, a B2B repository with two agreements that need to be deployed using the B2B console, and a test xml file that gets sent to the b2b/syncreceiver servlet using your favorite SOAP test tool[Read More]

Thursday May 10, 2012

Using Oracle B2B to send binary documents

Often times in a demonstration or a POC, B2B is asked to transport binary encoded files. This is actually very easy to do, but there are a number of restrictions you should be aware of when considering whether to use B2B for this or not.[Read More]

Monday Apr 30, 2012

Bidirectional Translation Web Services are now available in B2B 11g PS5 Release

Starting from SOA Suite PS5, bi-directional translation via web service is now available within the base install of B2B 11g. The note here describes the basic usage details.[Read More]

Tuesday Apr 10, 2012

Tuning B2B Server Engine Threads in SOA Suite 11g

B2B Server Properties from EM console can be used to tune the thread configuration of the B2B engine to improve overall B2B performance.[Read More]
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