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.
We have faced the same situation in my previous project and ended up with this architectural solution.
Followed creating a customer specific package and also created packages like EDI_Repository (contains only the EDI record structures/Schemas/dictonaries) and EDI_Maps which contains most common used EDI mapping services(eg:most commonly required/default segment mapping that extracts the data from the customer edi file and a folder with some utilities).These 2 packages will always exist in all the environments like(Dev/UAT/Prod)once the mappings are tested and approved.
When comes to the customer specific package build the maps if there is any custom mapping logic involved for the customer and beside invoking the services from the EDI_Maps package.
And this will relatively reduce the load of the package as well as dependencies when moving to testing/production.
So for us this solution makes easier to release the individual customer specific packages into different environments,currently scenario is in production.
Hi Bala
RMG is right as we too did the same. One package for records and one for common services and one pkg for each customer.
In your case you can disable one customer folder service from UAT to Production but this is not at all a good practice.
yes it leads to 150 packages having with minimal load,since we have one main package with commonly used maps,records etc…And this architecture is working fine.
If you some other approach,please share your ideas.
If you find that you simply have too many customers to manage your packages in that way - seek out another logical grouping that makes sense for your requirements.
Another thing to consider when you define your packages is team development. The more developers you have, the more you will benefit from a well organized, and probably, more fine grained package definition.
We are planning to re-design our package structure from package-by-application to package-by-function principle.
Example of functions would be: PO, Invoice, Shipment, Work Order etc
The current package-by-application structure looks like this:
Package application1
-folder application1
—folder publish
-----folder functionA
—folder subscribe
-----folder functionC
-----folder functionB
In example above we have four integration processes:
FunctionA Application1 ==> Application2 & Application3 (one source application to many target applications)
FunctionB Application3 ==> Application1 (one source to one target)
FunctionC Application2 & Application3 ==> Application1 (two source applications to one target application)
The new package structure to deliver same integration processes will look like:
Bad idea. Unless you have a very special customer, this leads to too a lot of package migrations with a large possibility of production interuptions unless you doing partial package migration with for example WmDeployer.
In general try to make sure that if you add a new partner, you don’t touch other production code.