Extending JDE integrations beyond JDE

I hear you saying - That's just don't make sense...  Unless you are integrating JDE with JDE, you are right - as every integration has 2 end points and therefore one of them beyond JDE.

I guess what I want to talk about in this blog post is thinking more broadly about how you solve JD Edwards integration challenges.  I'm going to talk specifically on how fusion5 uses a bicep based integration acceleration infrastructure as code to enable quick and easy integration beyond JDE.   I think it's important to think about your integrations beyond JDE and into what we might have traditionally called middleware.

Middleware is a good term for a consistent set of development tools between two or more systems... Therefore giving you a consistent method of connecting end points, monitoring integrations and stitching things together.  This middleware has always been dominated by the likes of MuleSoft, Boomi, Jitterbit and other players... Although I think that there is a paradigm shift going on at the moment.  What I am seeing is that more and more customers are using the native cloud services that Azure and AWS provide and build their "middleware" using native cloud services.  I believe that the following drives this decision:

• Cost - put simply you can pay per use and there is not large barrier to get started. You can get started nice and slow and build out the solution
• Access to talent.  Getting a developer that knows lambda (JS / python) or Azure functions is easier and can be applied to more situations than a dedicated middleware developer
• All modern endpoints are open.  Quite often new applications are built on a foundation of API's that they stick a front end on.  Therefore integration is not an afterthought, its actually built into the foundational architecture.  This means that connecting to said "Foundational architecture" is also easy and well documented.  restful saves us a lot of work
• connectors can be seen as a list of limitations.  Too many integration development tasks has lead me to believe that more often than not - an accelerator does not do what a customer wants.  It generally needs to be augmented or changed to get the job done.  Therefore, reading point 3 above - end points have this built in
• Supports ideals of smart end points, dumb pipes.  Think about JDE specifically and the orchestration studio.  This makes VERY smart end points, which can then be plugged into dumb pipes.  The JDE orchestrations take into consideration security, logic and customisations to present an API which can "do it all".
• Support for WAF / additional end point security
• Connectivity / HA / DR all built into the platform
• Security patching is native and often
• Logging and monitoring (think Azure monitor, think CloudWatch) can follow enterprise standards - critical for integrations and they are becoming more important that humans.  I don't want to trivialise your existence - but, I reckon that an integration can pump through more orders than a human any day of the week.  Therefore due to the importance logging and monitoring must be a first class citizen.

Wow, they are some good reasons to choose a hyperscaler to be your integration platform.  Fusion5 recognised this some time ago, and have been working on two different solutions on two different hyperscalers to address this opportunity. We have our bicep based Azure Integration Accelerator.  This is a set of code that accelerates and implements the use of standard Azure services to help support getting integrations securely from JDE and to the internet (and beyond).

Looking at the above, the orange ring (outer) is a middleware made up of our bicep deployment using all of the base Azure services to perform integration.  This is NOT just for JDE, it's for anything.  A consistent way of exposing JDE data and functionality to the internet.  Remember, this is super important for being secure.  For giving customers better ways of authenticating to get JDE data (not just a JDE username or JWT).  Personally I would not be putting any WebLogic ports facing the internet (you should see what I can do to the JDE ones...).  So this is how we can consume internet based integration points for JDE and also expose JDE to the internet.  The other huge advantage of using something in the middle is that JDE does not need to be up all of the time.  You can implement promise based integrations (asynchronous), which can allow for some levels of unavailability or at least retry ability when implementing integrations.

The blue circle is our fusion5 integration framework, which I have alluded to previously (like my last blog post), where we have put some bells and whistles into JDE to allow you to manage your orchestration based integrations more consistently.

The white circle is that standard JDE orchestration layer.

Note that orange and blue are not needed, you could expose JDE orchestrations to the internet - not that I would - but you could.

Let's talk a little bit more about the integration acceleration components that we create when we deploy our bicep based accelerator.

Some of the main components that are used are APIM, application insights and log analytics.  All built into the deployment.  OF course, things can easily get more complex, with the use of the service bus to provide more resilience.  However, what you do get out of the box is seriously impressive.

 

You can see from the screenshot above, this is the APIM definitions for the end points that we are exposing with APIM which are acting as a simple proxy for orchestrations.  You'll also note that we need to provide a key to be able to use the exposed APIM end point - here:

POST https://apim-poc-tatua-demo-f5dev-0001.azure-api.net/jdeorch/ORCH_EXT_CreateCustomer HTTP/1.1
Host: apim-poc-tatua-demo-f5dev-0001.azure-api.net
Ocp-Apim-Subscription-Key: <Place subscription key here>

Note that this passes on all of the parameters to JDE, but you have the ability to do any manipulation you want.  Therefore you could expose true restFUL end points for externals and then formulate your JDE calls using APIM and azure functions.  This would allow easy translation of payloads between systems.

Above shows application insights configured for the end point

Then using the application insights configuration for the API, we can then see above graphics of performance and errors coming from all of our calls.  Of course this is also logged using Azure logs, giving you the ability to query these with SQL like power.  You can also attach any of these events to end user alerts - it's got everything you need to build a very mature approach to business as usual.

AS you can see from the above there are many backed in queries for ripping the logs apart and fine tuning your monitoring.

Of course you have the ability to make this as complex or as simple as you want.  But -the main this is that you have the ability to consume and produce internet facing data securely from JDE and other sources.  This data can be asynchronous too.

Above you can see my postman call, this is heading for an AZURE link that has been exposed via APIM.  

This hits my APIM which can do anything (at the moment it does very little).

APIM (Azure API Management service) can inject credentials, it can coerce the payload, it can do subsequent lookups and validation and then call the actual JDE orchestrations.  At the same time providing all of the logging and debugging.

curl --location 'https://apim-poc-tatua-demo-f5dev-0001.azure-api.net/jdeorch/ORCH_EXT_GetItemAvailability' \

--header 'Ocp-Apim-Subscription-Key: 57c023c9aff049bbfdcggh4e84d638854' \

--header 'Content-Type: application/json' \

--header 'Authorization: Basic U00wMDAwMTpHb29FDS^54Q==' \

--data '{

"x-requestType":"ItemAvailability",

"x-pk":"",

"x-sourceSystem":"JDE",

"x-sourceTimestamp":"2023-10-06T03:58:44.000Z",

"x-conversationId":"c559e622-505f-4e46-bf64-a2734b130a70",

"x-correlationId":"ada827f1-8c25-4e5d-9109-ee422bef5fb5",

"x-sendingSystem":"JDE",

"x-sentTimestamp":"2023-10-06T03:58:44.000Z",

"x-TransactionType":"",

"inItemNumber":"1001",

"inBranchPlant":"",

"inLotNumber":"",

"inPrimaryBin":""

}'

You can see the request above.  Note that I have changed the basic auth and the subscription key - sorry hackers - you cannot use this.

At this stage the request has nothing to do with JDE, it's going to Azure.  Azure makes the decision on what to do with it.

Azure is busy logging the request and giving us performance information on my attempts.

We can see all of the performance and availability information above, this is critical for providing a consistent service to your customers.

Let's take this full circle, let's look what the Orchestration framework has to say about this?  Let's look at the development firstly:

We start the integration, check GUIDs etc.  Make sure that this is not a duplicate.  Note that this function is included in the framework.

If that is okay, then we work some magic on the media objects which maintain the logging for integrations.  Maintain the Media Attachment against an Integration Framework Conversation

We then update the conversation to give a marker of where we go up to and then call the actual internal worker orchestration to do the work and create the output.

Finally we mark the orchestration as complete and attach the output to the logs...  You can see that most of this is just copied, or comes from a template orchestration.

P57F5002 is the main workbench for integrations

You can see the 3 attachments which contains the JSON input, output and also the integration logs.  All of which are created in the framework:

Integration log:

21/11/2023 09:26:23 JDV920: Started : ORCH_EXT_GetItemAvailability
21/11/2023 09:26:23 JDV920: Conversation Status Updated to P : Processing
21/11/2023 09:26:24 JDV920: Conversation Process Status Updated to 105 : Orchestration Processing
21/11/2023 09:26:24 JDV920: Conversation Process Status Updated to 110 : Orchestration INT Process called, Asychronously
21/11/2023 09:26:24 JDV920: Started : ORCH_INT_GetItemAvailabilityProcessor
21/11/2023 09:26:24 JDV920: Started : ORCH_INT_GetItemAvailability
21/11/2023 09:26:24 JDV920: Item Availability Retrieved for Item 1001
21/11/2023 09:26:25 JDV920: End : ORCH_INT_GetItemAvailability
21/11/2023 09:26:25 JDV920: Conversation Status Updated to Y : Success
21/11/2023 09:26:25 JDV920: Conversation Process Status Updated to 400 : Orchestration Successful
21/11/2023 09:26:25 JDV920: End : ORCH_INT_GetItemAvailabilityProcessor
21/11/2023 09:26:25 JDV920: End : ORCH_EXT_GetItemAvailability

Input JSON

Text Attachment
Name:

{
 "x-requestType": "ItemAvailability",
 "x-pk": "",
 "x-sourceSystem": "JDE",
 "x-sourceTimestamp": "2023-10-06T03:58:44.000Z",
 "x-conversationId": "f0a8a64f-e67f-4198-98ea-d39372c8cb08",
 "x-correlationId": "27b61db2-21d1-4df8-8104-5a1ec2d2955d",
 "x-sendingSystem": "JDE",
 "x-sentTimestamp": "2023-10-06T03:58:44.000Z",
 "x-TransactionType": "",
 "inItemNumber": "1001",
 "inBranchPlant": "",
 "inLotNumber": "",
 "inPrimaryBin": ""
}

Output JSON

{
 "outShortItemNumber": "60003",
 "outBranchPlant": "*",
 "outItemNumber": "1001",
 "ItemAvailability": [
  {
   "outBranchPlant": "10",
   "outLotSerial": "",
   "outOnHand": "3.9000-",
   "outAvailable": "3.9000-",
   "outLocation": ". .",
   "outLotStatusCode": "",
   "outCommitted": "0.0000",
   "outSOWOSoftCommit": "0.0000",
   "outSOHardCommit": "0.0000",
   "outBackorder": "0.0000",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "10",
   "outLotSerial": "",
   "outOnHand": "3.9000-",
   "outAvailable": "3.9000-",
   "outLocation": "TOTAL:",
   "outLotStatusCode": "",
   "outCommitted": "0.0000",
   "outSOWOSoftCommit": "0.0000",
   "outSOHardCommit": "0.0000",
   "outBackorder": "0.0000",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "30",
   "outLotSerial": "",
   "outOnHand": ".0350",
   "outAvailable": ".0178",
   "outLocation": ". .",
   "outLotStatusCode": "",
   "outCommitted": ".0172",
   "outSOWOSoftCommit": ".0003",
   "outSOHardCommit": ".0169",
   "outBackorder": ".0001",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "30",
   "outLotSerial": "",
   "outOnHand": ".0350",
   "outAvailable": ".0178",
   "outLocation": "TOTAL:",
   "outLotStatusCode": "",
   "outCommitted": ".0172",
   "outSOWOSoftCommit": ".0003",
   "outSOHardCommit": ".0169",
   "outBackorder": ".0001",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "70",
   "outLotSerial": "",
   "outOnHand": ".0100",
   "outAvailable": ".0100",
   "outLocation": "",
   "outLotStatusCode": "",
   "outCommitted": "0.0000",
   "outSOWOSoftCommit": ".0063",
   "outSOHardCommit": "0.0000",
   "outBackorder": "0.0000",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "70",
   "outLotSerial": "",
   "outOnHand": ".0100",
   "outAvailable": ".0100",
   "outLocation": "TOTAL:",
   "outLotStatusCode": "",
   "outCommitted": "0.0000",
   "outSOWOSoftCommit": ".0063",
   "outSOHardCommit": "0.0000",
   "outBackorder": "0.0000",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "D30",
   "outLotSerial": "",
   "outOnHand": ".1000",
   "outAvailable": ".1000",
   "outLocation": ".  . .",
   "outLotStatusCode": "",
   "outCommitted": "0.0000",
   "outSOWOSoftCommit": "0.0000",
   "outSOHardCommit": "0.0000",
   "outBackorder": "0.0000",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "D30",
   "outLotSerial": "",
   "outOnHand": ".1000",
   "outAvailable": ".1000",
   "outLocation": "TOTAL:",
   "outLotStatusCode": "",
   "outCommitted": "0.0000",
   "outSOWOSoftCommit": "0.0000",
   "outSOHardCommit": "0.0000",
   "outBackorder": "0.0000",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "M30",
   "outLotSerial": "",
   "outOnHand": "0.0000",
   "outAvailable": "1.0000-",
   "outLocation": ". .",
   "outLotStatusCode": "",
   "outCommitted": "1.0000",
   "outSOWOSoftCommit": "0.0000",
   "outSOHardCommit": "0.0000",
   "outBackorder": "0.0000",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "M30",
   "outLotSerial": "",
   "outOnHand": "0.0000",
   "outAvailable": "1.0000-",
   "outLocation": "TOTAL:",
   "outLotStatusCode": "",
   "outCommitted": "1.0000",
   "outSOWOSoftCommit": "0.0000",
   "outSOHardCommit": "0.0000",
   "outBackorder": "0.0000",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "7600",
   "outLotSerial": "",
   "outOnHand": "0.0000",
   "outAvailable": "0.0000",
   "outLocation": "P",
   "outLotStatusCode": "",
   "outCommitted": "0.0000",
   "outSOWOSoftCommit": "0.0000",
   "outSOHardCommit": "0.0000",
   "outBackorder": "0.0000",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "7600",
   "outLotSerial": "",
   "outOnHand": "0.0000",
   "outAvailable": "0.0000",
   "outLocation": "TOTAL:",
   "outLotStatusCode": "",
   "outCommitted": "0.0000",
   "outSOWOSoftCommit": "0.0000",
   "outSOHardCommit": "0.0000",
   "outBackorder": "0.0000",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  },
  {
   "outBranchPlant": "",
   "outLotSerial": "",
   "outOnHand": "3.7550-",
   "outAvailable": "4.7722-",
   "outLocation": "GRAND TOTAL:",
   "outLotStatusCode": "",
   "outCommitted": "1.0172",
   "outSOWOSoftCommit": ".0066",
   "outSOHardCommit": ".0169",
   "outBackorder": ".0001",
   "outFutureCommit": "0.0000",
   "outOnSOOther1": "0.0000",
   "outOnSOOther2": "0.0000"
  }
 ],
 "out_ErrorFlag": "0"
}