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"
}

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.

JDE and Java licensing

I know, I know - not enough blogging.

This might be a cracker for you!

Here is one that might be a little interesting.  What is big red doing with Java licensing and how this may affect you and your JDE.

Java SE Universal Subscription is what we are dealing with, an announcement earlier this year.  So in 2023 in Jan it was announced that if you are using java, then you need to pay for all employees in your company.  Not just the ones that are using Java - yay.

What licensing is currently offering the following licences:

See the current price list here: Oracle Java SE Universal Subscription Price List

There has been a significant change, if you have needed to download java from oracle, then you probably should be paying for it.  

The above has been stolen from a much better article -  https://redresscompliance.com/decoding-oracle-java-licensing-java-licensing-changes-2023/

Let's clarify exactly what Java SE is and why you need it...  Java SE is the product name for all of the below...  This diagram shows you the relationship between jdk, jre and jvm.

Java SE contains both the JRE (Java Runtime envrionment) and JDK (Java Development Kit).  In general a JDK contains a JRE.

So, if you have any of the above items on your machine, then there is a chance that you need to licence them.  If your company is writing code that ends with .java - this means there is a good chance that you might need a licence - but there are some exceptions...  

Remember, some bases to compile and run a java program - you will need a java environment, which includes an JDK.  javac is part of the jdk.

So the above uses the jdk to create a class file and the JRE to run the program.  And, I need a licence...  Or do I?

Take a look what my cheeky mac says:

shannonmoir@f5au367 ~ % which java

/usr/bin/java

shannonmoir@f5au367 ~ % java -version 

The operation couldn’t be completed. Unable to locate a Java Runtime.

Please visit http://www.java.com for information on installing Java.

So it's certainly not shipped by default in a new OS.  I need to google java download and see

This helps too - as it has the relevant links

Important Oracle Java License Information

The Oracle Java License changed for releases starting April 16, 2019.

The Oracle Technology Network License Agreement for Oracle Java SE is substantially different from prior Oracle Java licenses. This license permits certain uses, such as personal use and development use, at no cost -- but other uses authorized under prior Oracle Java licenses may no longer be available. Please review the terms carefully before downloading and using this product. An FAQ is available here.

Commercial license and support is available with a low cost Java SE Subscription.

So it seems that me as a developer is all good, but if I ship my magnificent code listed above to a customer...  They need java to run it...  So - they need to pay up!  The classic user pays.  

Back to JDE:

Let's think about where we use Java for JDE and then determine if Java SE license is required.

So...  

• weblogic uses Java
• a local web instance uses Java - which is weblogic
• BIP uses java on enterprise servers
• Server Manager (agents and console) use java
• kernels (metadata) use java

What version of Java do I need for JDE?  Everything at the moment point back to version 8.

Server version	JDK Version
Oracle WebLogic Server 12c (12.2.1.3)	Oracle JDK 1.8.0_131+ Refer to the Certify system for the exact versions
Oracle WebLogic Server 12c (12.2.1.4)	Oracle JDK 1.8.0_211+ Refer to the Certify system for the exact versions.
Oracle Weblogic Server 14c (14.1.1.0.0)	Oracle JDK 1.8.0_251+ Refer to the Certify system for the exact versions.

We are limited to version 8 at this stage, which has a supported roadmap until 2030...  as seen here: https://www.oracle.com/au/java/technologies/downloads/#java21

What you will also notice is that the java release roadmap is very confusing.  From a JDE perspective, we follow MTR's and that seems to be limited to version 8.  It's been going crazy over the last year, kinda fitting in with the oracle release numbers, 21 at the moment.

Above shows a little hint about Java SE available to run with other licensed oracle products...

It's actually easy to see what is using java, just go to your task manager in your operating system of choice.  You'll see java running and therefore you are using licences. 

As the screen shot above indicates, about using Java with oracle products os that there is a special way of inheriting your license.  I'm guessing that this applies to JDE and OTF (Oracle technology foundation)...  Let's look further. 

The table above says that Java 8 can only be licensed with:

My Oracle Support (Oracle Customers Only) and Oracle Technology Network License Agreement for Java SE for Personal, Development and other Users only.

MOS and OTN.  Well, we are MOS for JDE maintenance.

My.Oracle.Support Note 1557737.1 - Support Entitlement for Java SE When Used As Part of Another Oracle Product

Looks like we are nearly there... Wow, this is far more complex than I originally thought.  

I'm probably not allowed to copy everything verbatim, but the essence of the MOS support note 1557737.1 above states:

Oracle customers of Oracle products that use the Oracle JRE or Oracle JDK are entitled, without the need to separately purchase Oracle Java SE Subscriptions, to the following:

• Download and use Oracle Java SE updates, patches, and tools for use with the licensed Oracle product. Customers are only entitled to download such Java SE versions as are required by their Oracle product.
• Install and use such Java SE updates, patches, and tools to develop or deploy an Oracle product.
• Customers can file service requests for Java issues against an Oracle product, but not directly against Java SE.

In most cases, this means that Oracle customers are expected to download and install Oracle Java SE updates and patches only on those servers licensed to use an Oracle product and to configure the downloaded Java SE version to be used only with the Oracle product.

Some Oracle products are licensed as server products but also contain client applications or client-side libraries. For such Oracle products, Java SE updates and patches can be installed on the client side and either used to run only client applications provided by Oracle or used to run custom client applications built using client libraries provided as part of the Oracle product and accessed through a proprietary, product-specific protocol.

Examples:

• Customer is using WebLogic Server. Customer is entitled to download and use Java SE updates and patches to run WebLogic Server. This example is applicable for any server-side Oracle product based on Java and includes most Oracle middleware and applications products.
• Customer has built a custom client application that uses HTTP to talk to WebLogic Server. The customer is NOT entitled to download and install Java SE updates and patches on the client, since the client application is not using a product-specific protocol.
• Customer has built a client application that uses JDBC drivers to connect to a licensed instance of an Oracle database.  The customer is NOT entitled to download and install Java SE updates and patches on the client, because JDBC drivers do not use a product-specific protocol.

If the customer’s entitlement to the supported Oracle product ends, the customer’s entitlement to any Java SE product downloaded under this entitlement also is ended.

That last paragraph is a doozy, I read that to mean - if you are not paying maintenance then you cannot use Java SE anymore without a separate license.  Nice.

Summary:

My summary is that if you are paying maintenance to oracle for JDE, you can use Java 8 for your JDE products and also the oracle technology foundation products that have been included in your bundle and use oracle.  BUT - if your are writing code in java and connecting to these databases / services - then you might need a license.

Infocus 2023

Lucky me is going to be in Denver for Infocus 2023.

Glenn and I are going to present on generative AI and ERP insights, look out for us on the Thursday afternoon.

https://questoraclecommunity.org/events/conferences/infocus/

Look forward to seeing all of the community gather for this JD Edwards event.

Understanding Automation & AI use cases in JD Edwards

Presented by: Shannon Moir, Fusion5

Get beyond the hype and into real world scenarios on how you can find out where you can apply automation or AI to get the mos

t benefit for your business and end users. Fusion5 will show you how you can see exactly what your users are doing in JD Edwards via their ERP Insights tool. This unequivocal analysis of user patterns allows a business to hone in on their JDE hotspots and make the user experience better. We show you some of the cool ChatGPT inspired innovation that we have been implementing down under - we’re told the same code will work in the northern hemisphere too. If time allows, we’ll tell tales about throwing another shrimp on the “barbee” and also riding kangaroos to work. 

JD Edwards