6645863

Trading Partner Management Part 3: Processing Groups - Advanced Routing

Blog Post created by 6645863 Employee on Apr 2, 2017

In our last post, we talked about the ability quickly to adjust who participates in one or more integration processes by using the new Processing Group components. However, we were left with the critical question: “What happens when each customer needs to process its data differently?” This is a very common scenario in the B2B world. As we like to say, each customer follows the standard differently.

 

Let's take a look at how Processing Groups simplify routing logic for trading partner processes.

 

 

 For additional background and context on all the recent Trading Partner management features, be sure to read Trading Partner Management Part 1: Organizations

 

How can Processing Groups help?

As discussed previously, the Processing Group can control two key aspects of integration processing:

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

 

You may be familiar with the Process Route shape. This shape allows dynamic routing of data based on key properties within the data. It was a natural progression to extend these data routing capabilities to the new Processing Group component. The route definitions in a Processing Group allow you to specify a subprocess for each document, partner, or standard.

 

Motivation

Currently, adding unique processing for a trading partner requires changes to a primary process, which may contain other unrelated business logic changes that are picked up on redeployment of the process. Processing Groups allow you to define routes for data independently and more simply, and the group routing is subsequently handled by the process by using the Process Route shape. By deploying the Processing Group separately, you can modify your routing logic without picking up unrelated changes in your primary process.

 

Additionally, if one of your customers changes their mapping, you can redeploy their process independently -- no change to either your master process or the group routing! 

 

Sample Use Case: Routing

I have added LA Supplies to my inbound processing, but their 940 is slightly different from my existing partners. In a world without processing groups, I can use our Route shapes to specify that this partner’s 940 should go to a different subprocess.

 

This usually means:

  • Add a value to an existing route shape to specify that this new partner should go to a new subprocess
  • Possibly add a route tree of all document types that this partner processes, which can get noisy if they have several incoming documents.

 

In each of these cases, the simple act of adding a partner to a flow, adding a document type, changing an underlying subprocess, or adjusting partner routing requires a redeployment of the master process including any branches or subprocesses for other trading partners. In large-scale deployments there’s a higher risk of picking up unintended changes.

 

Let’s see how the Processing Group can help with this.

 

How it Works

  • A Processing Group component is independently deployable and not packaged with the process.
    • You pay a higher design and maintenance cost up front to generate and deploy a group, but...
    • You gain the benefit of changing routes without redeploying your master process
  • The routing rules for partners and documents may be edited then deployed.
    • Processes need to be deployed separately, but…
    • Processes can be deployed separately! You can edit how a given partner’s process works without deploying everything else.
    • You can route documents by trading partner and/or by document type, depending on your situation.
  • What this means
    • You can edit a single partner’s document process or map and redeploy that process without impacting your other customers or the master process.
    • You can add a participant to the Processing Group and add routes for that participant without impacting your other customers or the master process.
    • You can adjust and consolidate existing routes by having a default route at either the document or standard level

 

Improved Routing: From this...

 

To this -- use the Process Route shape!

 

Process Route shape configuration...

Sample Use Case: Routing Improved

I can define routing rules in one of two ways:

  1. Everyone mostly conforms to my standards -- Route By Document, because all 940s are the same with few exceptions. I can still define per-partner exceptions.
  2. Each partner has a different standard for the same document -- Route By Partner, because each partner is unique.

 

Within the Processing Group, I can specify which of these route styles I want to use. This will allow me to associate processes with these partners and allow use of the Processing Group in a Process Route shape.

  • Define routes in the Processing Group
  • Your route shape tree in your master process becomes a single Process Route shape.
  • Processes must be deployed independently, like process route or API. This means that they can be updated independently without affecting master business logic or other partners’ processes.

 

 

How Can I Start Using It

To start using the Processing Group as a process router:

  1. Create (or choose) a Processing Group that will function as your new router
  2. Move one partner’s route into the Processing Group
  3. Replace this partner's route branch in the original process with a new Process Route shape using this Processing Group.
  4. Redeploy the master process (since you changed how routes work), deploy the processing group, and deploy the relevant route processes.

 

Your process should now be using the process route and Processing Group for this partner’s documents.

 

Considerations for Use

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

  • We are working to enhance deployment to suggest that you deploy related artifacts, so this cost will be mitigated in the future.
  • The Processing Group component deployment shares the same concepts and considerations as the Process Route component, which are discussed in detail here.

 

Check out the new Processing Group component when you have a chance. For more details please see Processing Group components.

 

Next up: Communication Channels...

 

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 knows where they keep the good coffee.

Outcomes