Orchestration Framework for JD Edwards

Add some maturity to your orchestrations.

Orchestrations are great, right?  Yes!  Everyone is using orchestrations all of the time.  They have the ability of sharing logic and data easily and securely.  It's a critical design ideal that we implement the logic in the end points, not the pipes - and that is exactly what orchestrations allow you to do.

They also form the building blocks of extensibility.  Being proficient in orchestrations allows you to take advantage of all of the additional functionality that is being built into User Defined Objects.  Honestly, if you are not calling orchestrations with form extensions - what are you doing?  If you are not calling orchestrations in workflow's - what are you doing?

We like to demonstrate a very mature approach to JD Edwards integrations.  We have accelerators for Azure, AWS and OIC to help get that JD Edwards data and logic outside the enterprise.

The above shows our Azure centric integration ideals.  Allowing you to plug in any of the power platform securely (yes using JWT) back to JDE.  No crazy password prompts, nice and native solution.  The blue ring is our orchestration framework that sits outside the orchestration functionality.  The orange ring in this design represents our Azure Integration Framework, which is a set of patterns to accelerate using Azure as your chosen middleware.

Fusion5 use orchestrations as the back bone of their mobility and integration solutions, but we found a couple of opportunities that we needed a solution for.

We needed a solution that would address some shortfalls of the standard orchestrations:

• Lack of visibility for logging, inputs and outputs in a central location
• No historical data for previous runs
• Inability to capture inputs and outputs (at certain tools releases)
• Difficult troubleshooting
• No centralized management console
• No enforcing of consistent approaches / development standards
• Native ability for asynchronous function calls

So the amazing team at Fusion5 have created the orchestration framework.  The name says it all, it is a standardization of integration methods and patterns as implemented as orchestrations in JD Edwards.  

We have developed a "plug and play" suite of enhancements to improve your orchestration developments.  Our patterns enforce standards that make logging easy and debugging easier.  We provide you with a one stop shop for controlling your orchestrations, defining your callbacks and overall management and monitoring of anything related to orchestrations.

Our centralized management console allows end users and/or developers to look at the payloads and work out why something has failed or not.  If the orchestration allows for resend, then this can also be triggered for outbound events.  This allows you to have the right people solving integration problems with all of the information that they need at their fingertips.

We ship the code and the samples to you, which show you how to code additional headers that provide unique identification throughout the JDE processes - but also identify the complete lifecycle of transactions through your middleware of choice.

Instead of learning all of this "on the fly", you can lay out mature orchestrations with all of the mandatory header information that you need to manage and monitor your integrations.  You can see from the above that we have mandatory headers which store GUIDs to track correlation and conversation IDs - to always have a complete picture of where an integration got to.

If you'd like to know more, please get in touch.  This is sold as a subscription - so that you can get all of the juicy updates - or as a one off.

Read more here:

https://www.fusion5.com.au/jd-edwards/jde-orchestration-integration-framework/

We also recommend if you want to add a heap of maturity to your orchestrations, then we could also write the first 2 or 3 in anger - making sure that you are using the framework effectively and allow you to solve all of your integration challenges consistently.

I'm going to try and do a series of blogs focused on integration and JD Edwards.  Also showing you how we lay down a bicep based Azure integration framework - preparing you for a proper internet facing middleware solution - where you only pay for what you need.  This allows you to take advantage of the Azure Service Bus, APIM and more to protect JD Edwards - whether you are on premise or in the cloud already.

I'll also talk about our native RTE to Azure Service Bus replication software, so you can capture those important outbound events in the cloud and act of them from there.   This was previously blogged here:  https://shannonscncjdeblog.blogspot.com/2020/05/rte-to-azure-great-escape.html 

Finally I hope to document what we are doing with event filtering, which is a more advanced way of controlling the events that are being fired out of JDE, as they can sometimes be a little overwhelming.

So - watch this space for integration education updates.