Trading Partner Management Part 2: Processing Groups - Groups and Membership

Blog Post created by 6645863 Employee on Mar 27, 2017

Welcome to another in the series of articles about AtomSphere’s enhanced EDI capabilities. Last time we discussed how organizing Trading Partner settings for your customers can be simpler and more informative with Organization components.


For additional background and context, be sure to read Trading Partner Management Part 1: Organizations

In this article, let’s start talking about Processing Groups. Process Groups are the most significant update among these new features--so significant that we'll be breaking the discussion up over two articles!



What are Processing Groups?

Where an Organization associates same-company standards that are used in unrelated integrations, a Processing Group associates different companies’ settings to more easily participate in the same integrations.


A Processing Group is a new, deployable component type that allows independent management of two important aspects of your integration processes:

  1. Membership - Who participates in these processes?
  2. Routing - How do I process the data?

Today we’ll focus on Membership.



In an AtomSphere process, you can currently configure a list of trading partners inline either within the Start shape (inbound) or a Trading Partner shape. Let’s say you’re a warehousing company that receives shipment requests from the companies you service. It can be cumbersome to add a new participant to an existing process, especially if each Trading Partner has its own flavor of a particular document standard.


The Processing Group allows you to more easily (and independently) manage the participants in an integration by creating a separately-deployable list of Trading Partners that will participate in one or more process flows.


Sample Use Case

I currently receive warehouse orders (940s) from iMagin and Nuschke Technologies. I am onboarding a new partner "LA Supplies" and need to add them into my existing, shared AS2 inbound "master" process:



Previously, for a simple AS2 listener process you would need to perform the following steps:

  • Add LA Supplies to the Start shape’s list of trading partners.
  • Add LA Supplies to the list in the outbound Trading Partner shape used to send Acknowledgments (optionally).
  • Redeploy the AS2 inbound process.
    • Teaser Note: Often the new trading partner may require its own processing logic, maps, etc. which would typically be implemented in a subprocess specific to that trading partner and invoked using a Route and Process Call shapes. Whenever you need to make a change to the given trading partner's subprocess, you must redeploy the master process, however that will also redeploy any other trading partners' subprocesses--some of which may not be ready to deploy yet. This is a really important point that we'll cover in the next post.


Issues with this approach:

  • You need to remember to add your partner to all relevant shapes.
  • Redeploying the master process will pick up any other changes in the process tree, not just your new partner definition.

There’s a better way to deal with growing business: the Processing Group.


How it Works

A Processing Group component is independently deployable and not packaged with the process. This means:

  • You pay a higher design and maintenance cost up front to generate and deploy a group, but...
  • You gain the benefit of adding and removing members without changing your underlying business logic


Editing the membership list of a Processing Group can change who participates in one or more integration processes without needing to redeploy the process(es) in which the group is referenced.


Sample Use Case: Membership Improved!

I can create and reference a “My Warehouse Customers” processing group for all of my partners that will trade the 940 and other warehouse documents.

  • Attach this group to the relevant Start and Trading Partner shapes, rather than configuring the individual trading partners directly in the shape.
  • Deploy this group.
  • When I need to add a new partner, I add it to the Processing Group and redeploy the Processing Group only--no need to deploy the process again.


Create the Processing Group component:


Configure trading partners within the Processing Group:


Configure the Start shape to use a Processing Group instead of a list:


Deploy the Processing Group separately:


How Can I Start Using It

We currently allow you to swap back and forth in the Start shape and Trading Partner shape between an inline list and Processing Group.


A simple way to start using the Processing Group on an inbound process is to:

  1. Create a new Processing Group.
  2. Add the partners from an existing process Start shape to the Processing Group.
  3. Change the Start and Trading Partner (acknowledgment) shapes to use the new Processing Group.
  4. Deploy the Processing Group and redeploy the process.


Your process should now be using the Processing Group to identify the partners who participate in the process. Note that you can now add or edit partner information and redeploy the Processing Group to pick up any configuration changes. This will not impact the business logic of your process.


Considerations for Use

You should consider using a Processing Group when:

  1. You are frequently adding participants to an integration process
  2. A single process is servicing multiple partners and you want to be able to deploy independently each partner's unique business logic -- we'll talk about this next time.
  3. (Forthcoming) You have business users who are allowed to edit partner configurations and settings but who should not have access to edit your process logic. 


You incur a higher design and deployment cost (groups and their processes must be deployed independently) for the benefit of greater flexibility and more fine-grained change control.


Being able quickly to edit the participants in a process is great, but what happens when each participant processes its data differently? Adjustments to the process are still required to route the data to a different subprocess or map.


Stay tuned for the next post which will tackle the routing capability of Processing Groups. In the meantime, check out the new Processing Group component when you have a chance. For more details please see Processing Group components.


Eric Fennell is a Senior Principal Engineer with over 15 years of experience in development and integration. He is passionate about standardization and usability, and he's not just a developer, he's also a client.