Hi,

We are in the process of implementing a B2B Integration where we map the customers EDI purchase orders to our internal proprietary format to feed in to one of our enterprise application for further processing. We develop the required mappings as individual flow services one per customer. Before starting of this project we were not sure of the total no of customers. All our customer mappings were residing in a single package in the integration server. During the intial stages of the project everything was fine and we were able to move indivdual customers in to UAT/PRODUCTION without much trouble. Issues started creeping up when the number of customers started growing. Since all the customer mappings were residing in one single package, migration became a problem. Take a case where we migrate two customer mappings to UAT (in a single release) and after UAT we wanted to migrate only one customer to PRODUCTION. We were not able to do this. In this particular scenario one customer is dependant on the other customer’s UAT completion which absolutely not acceptable.

Hence the issue here is of two fold, one is the size of the package which is growing like anything as we contantly keep on adding flow services for new customers. The other issue is the problem of decoupling customers while migration. Eventhough we create multiple release one per customer say release1 and release2 we cannot migrate release2 to PRODUCTION unless we complete the UAT successfully for release1.

Is it advisable to have a customer based package i.e. one package for one customer ?.
Is there any recommended maximum size of the package ?.

Is there anyone who had a similar experience and would like to share the best practices (if any) that they followed.

Any inputs would be greatly appreciated.

Regards
Balachandar

Hi,
Here are some steps that you can use.

1. Try to create generic flows that are highly reusable.
2. Identify and group flows into different packages according to their functionality.
3. Try to create java based flows whenever there are multiple and high number of looping involved.

Hope this helps and good luck with your project.
Thanks

Balachandar:

If I understand you correctly you are repeating tasks customizing your solution for different customers.

I would suggest:

1. Create a baseline (common solution) with a baseline package name
2. Unit test and Product test this package
3. Create a new Package with customer name
4. The services that are customized for the client will reside in this package with the same namespace and the baseline package. Although you will have to rename the serive in the baseline package.
5. This would provide a best practise approach going forward. Let me know if you have more questions.
   Animesh Gupta
   IM AOL: indoraj

Noticed that the use of the canonical was not mentioned in either answer. Yes, you should create some reusability to the code, but you can also simplify your processes by pooling commonalities and seperating out non-conforming elements. For example:

-Receive customer documents in seperate packages.
-Map the data to a canonical, or superset of data.
-Be sure to include a customer ID number to note the document source
-Be sure to include a set of undefined fields (name/value pairs, etc.)
-Once you have the canonical, you can perform the standard business rules across all customers
-Using the customer ID, you can customize specific customer business rules
-Get stored XML/map file for each customer (stored in the customer package)
-Use name/value pairs to extract customer specific values (logic in the customer package)
-Output is the master data set that can be sent to back end system.

Upgrading customer packages requires just migrating those packages. The core functionality remains in tact, and essentially unchanged.

Hope that gives some guidance…