E9.2 Orchestrator versus development

[bjouzier]

Hello,

Logic extension or groovy Orchestrator components, along with capabilities of form extensions to closely link orchestrations with JDE HTML applications, now raise the question of opportunity to use Orchestrator versus devlopment.

By example, this occurs in following situations :

• developping a UBE with Report Design Aid versus creating on orchestration based on a logic extension component iterating the result of a Data Request component
• modifying Event rule of an application in Form Design Aid versus associating an orchestration with an Event-Rule event using form extension
• ...

Some considerations can be discussed :

• development in Form Desing Aid or Report Design Aid should have better performances than orchestration ?
• in production monitoring of UBE should be more easy than monitoring orchestrations ?
• for upgrading to JDE new upgrades, orchestration is more straight-forward than development ?
• orchestration is more easy to promote, for UDO management is more easy than package management ?
• Development competencies are more easy to find than orchestrator competencies ?
• With orchestrator Advanced users should be more autonomous to make changes ?
• ...

Of course there is no closing answer on such a global topic, but if somebody has some hints about it, or some experience on some particular questions in it , or some particular piece of good practice I should be interested to discuss.

Kind regards,
Bruno.

 

[DaveWagoner]

I was a JDE developer hellbent on customizing for most of my career. Now I'm all-in on staying vanilla and using UDOs via FEXT/Orch/LEX.

There have been some great and passionate discussions at conference advocating for one side or the other, but as I've found recently there is room for each. Default to staying de-customized, but on occasion you will need to customize old-school.

 

[JohnDanter2]

I would say that it depends what you are doing and what you are most comfortable with.
Most E1 objects are event based so if you know those events and their sequence then it's fairly simple to place code in the relevant event to meet your tasks.
So Init section, Do section, End section etc at a very basic level is the same as a data request and an ORCH iterrating over the data request.
How would you do level breaks in ORCHs? I'm sure it's possble but I'd scratch my head, where as in a UBE I'd knwo in a heartbeat as I'm 20+ years used to it.

I try to use UDOs where I can these days and ORCHs too but only until 9.2.8 could we modify BSVWs on the web, up until then you had no choice but to use a FAT client

Also, sometimes a base E1 BSFN or process executes a whole string of other BSFN and does SQL updates in a fixed manner etc that you may not want. So you have to intercept that path in the BSFNs with a modifaction OR you have to let E1 do it's thing and THEN clean up the update you no longer want after the fact.
Sometimes thats ok other times it isnt. When it isn't you have no choice but to stop it mid flow and that's only possible the old fashioned way most of the time.

So both approaches have pros and cons

 

[jolly]

It’s all development. The line between OMW development and UDO’s has really dissolved now. With logic extensions and tableIO you can do dangerous interventionist stuff like any other developer. The great news is that you are often not needing to touch JDE code.

 

[Kevin Long]

I was a JDE developer hellbent on customizing for most of my career. Now I'm all-in on staying vanilla and using UDOs via FEXT/Orch/LEX.

There have been some great and passionate discussions at conference advocating for one side or the other, but as I've found recently there is room for each. Default to staying de-customized, but on occasion you will need to customize old-school.

I absolutely agree. Whenever possible, try to avoid changing base JDE code, but it may not always be possible. I do see customers looking much more closely at UDOs to create new solutions and replace existing customizations, especially as User Defined Objects continue to evolve and reduce the need for modifying base JDE objects. The other thing UDOs bring to the table, especially with orchestrations, is the ability to tightly integrate external solutions with JDE much more easily than in the past.

 

[bjouzier]

Thanks a lot for all this considerations, I will take care of all.

I have a subsequent question : does anyone experiment performance issues when calling orchestrations from FormExtensions, for example associated to events like button-clicked or DialogIsInitialized, compare to do the same by directly changing the ER in Form Design Aid ?

Kind Regards,
Bruno.

 

[DaveWagoner]

Have been pleasantly surprised calling orchs/lex's from fext's. I haven't written anything TOO resource intensive tied to a fext yet though.

 

[eydeak]

Once you get into Logic Extensions, it's basically a different way to write code. You still need to understand the basics of coding (if/then, looping...) to be able to do it.

 

[Kevin Long]

The Logic Extension would run on a JAS server, so I don't think performance would normally be an issue as compare to code in form event. In fact, Logic Extensions do bring some performance benefits in Release 23 such as Aggregation. It is nice to be able to push aggregation back to the database. However, it is important not to overstate what is possible with a LEX regarding interacting with an existing form. For example, I would love to be able to push a button from a LEX. It is still relatively early days for these capabilities and it will be interesting to see how they evolve.

 

[BetoJDE]

The Logic Extension would run on a JAS server, so I don't think performance would normally be an issue as compare to code in form event. In fact, Logic Extensions do bring some performance benefits in Release 23 such as Aggregation. It is nice to be able to push aggregation back to the database. However, it is important not to overstate what is possible with a LEX regarding interacting with an existing form. For example, I would love to be able to push a button from a LEX. It is still relatively early days for these capabilities and it will be interesting to see how they evolve.

The performance is a big issue in this cases, because LEX are very slow to execute, i guest that the architecture between AIS - JAS and Enterprise made the waiting times for a Web Services Response in some cases a problem.
Currently i use the Lex to show custom errors in a web service, for example if i have a Data Request to show information about a product for F4101 if the product doesn´t exist the data request show an empty json and the HTML response is 200 (OK), but i can put a rule to validate if the number of record is less than 1 and show a a DD error using a LEX and the HTML response put 500 (Error)

 

[BetoJDE]

Thanks a lot for all this considerations, I will take care of all.

I have a subsequent question : does anyone experiment performance issues when calling orchestrations from FormExtensions, for example associated to events like button-clicked or DialogIsInitialized, compare to do the same by directly changing the ER in Form Design Aid ?

Kind Regards,
Bruno.

I prefer use a FormExtensions, because you can control the security for activate and desactivate and avoid made update packages, the functionality is the same if you doesn't need a especial logic.

 

[StewartSchatz]

I hate to sound like a typical SysAdmin but from this CNC Administrator's perspective, any of the "citizen developer" options can negatively affect system performance.

There is definitely a time and place for them, I just ask that you be careful and involve your CNC Admin early in the process. Testing 100s of records successfully in DV is much different than processing 1000s of records in PD. Also, do your best to use the server in the your testing rather than your local Dev Client. I know its a couple more hoops to jump through but it will give you a better idea of how PD will perform.

I've seen several instances of Orchestrations trying to process 1000s of records and bring even the beefiest JAS server to a halt. If it's a batch process, use a UBE.

Just my opinion. Take it or leave it. I'll be around to clean up the mess afterwards.

 

[DaveWagoner]

I hate to sound like a typical SysAdmin but from this CNC Administrator's perspective, any of the "citizen developer" options can negatively affect system performance.

There is definitely a time and place for them, I just ask that you be careful and involve your CNC Admin early in the process. Testing 100s of records successfully in DV is much different than processing 1000s of records in PD. Also, do your best to use the server in the your testing rather than your local Dev Client. I know its a couple more hoops to jump through but it will give you a better idea of how PD will perform.

I've seen several instances of Orchestrations trying to process 1000s of records and bring even the beefiest JAS server to a halt. If it's a batch process, use a UBE.

Just my opinion. Take it or leave it. I'll be around to clean up the mess afterwards.

I've been super heavy on orchs to the detriment of system performance, lately.

Trying to use orch for data conversions has been a tactical mistake committed by me, very recently. A data conversion that would take z-files a few minutes takes orch 8hrs. A step backwards even though I'm playing with 20+year newer toys.

Sysadmins and DBAs are always worth listening to, sometimes we devs make a mess with our shiny new toys.

 

[Kevin Long]

I've been super heavy on orchs to the detriment of system performance, lately.

Trying to use orch for data conversions has been a tactical mistake committed by me, very recently. A data conversion that would take z-files a few minutes takes orch 8hrs. A step backwards even though I'm playing with 20+year newer toys.

Sysadmins and DBAs are always worth listening to, sometimes we devs make a mess with our shiny new toys.

It is very true, the potential for making a mess is there. Low code solutions can be whipped together very quickly, but they don't often scale very well. However, I think orchestrator gets a worse reputation than it deserves because we don't talk enough about how to optimize orchestrations. That isn't to say it will ever outperform a UBE or a table conversion, but leveraging tools like the AIS server APIs, business functions, and logic extensions, can help a lot.

 

[bjouzier]

I hate to sound like a typical SysAdmin but from this CNC Administrator's perspective, any of the "citizen developer" options can negatively affect system performance.

There is definitely a time and place for them, I just ask that you be careful and involve your CNC Admin early in the process. Testing 100s of records successfully in DV is much different than processing 1000s of records in PD. Also, do your best to use the server in the your testing rather than your local Dev Client. I know its a couple more hoops to jump through but it will give you a better idea of how PD will perform.

I've seen several instances of Orchestrations trying to process 1000s of records and bring even the beefiest JAS server to a halt. If it's a batch process, use a UBE.

Just my opinion. Take it or leave it. I'll be around to clean up the mess afterwards.

Thanks a lot, I fully agree that CNC should be involved.
It seems two me, but I have more development side than CNC-side, there are distinct performance topics :

1 - Performance of the orchestration itself : I imagine for this we can get an idea by running the orchesrtation from Orchestrator studio

2 - Performance of calling many times little orchestrations, through form extension associations. For example if I have an orchestration that in itself executes in less than a second, what happens if through form extensions I associate it with the Find event of an application form. In this case the orchestration can be called many times per hour by twenty users working in JDE. Is it to be avoided for performance issue ?

My concern is mainly on point 2 (point 1 is more easy for me to check with Studio).

 

[Kevin Long]

Thanks a lot, I fully agree that CNC should be involved.
It seems two me, but I have more development side than CNC-side, there are distinct performance topics :

1 - Performance of the orchestration itself : I imagine for this we can get an idea by running the orchesrtation from Orchestrator studio

2 - Performance of calling many times little orchestrations, through form extension associations. For example if I have an orchestration that in itself executes in less than a second, what happens if through form extensions I associate it with the Find event of an application form. In this case the orchestration can be called many times per hour by twenty users working in JDE. Is it to be avoided for performance issue ?

My concern is mainly on point 2 (point 1 is more easy for me to check with Studio).

I would say this comes down to using the right tool to meet the requirements. Now that you can call a Logic Extension directly through a Form Extension, I would avoid using an Orchestration for anything interactive on the form unless I need to connect to an external system. Orchestrations are very useful for pushing/pulling data from other systems. Logic extensions really seem to be much closer to running NER on form event than an orchestration.

Form Control Extensions are not a full replacement for Form Design Aid. However, this feature is not yet a year old and I do see customers starting to take advantage and enforcing additional business rules without a developer. I am very interested to see what capabilities might be added in the next year or two.

 

[bjouzier]

I would say this comes down to using the right tool to meet the requirements. Now that you can call a Logic Extension directly through a Form Extension, I would avoid using an Orchestration for anything interactive on the form unless I need to connect to an external system. Orchestrations are very useful for pushing/pulling data from other systems. Logic extensions really seem to be much closer to running NER on form event than an orchestration.

Form Control Extensions are not a full replacement for Form Design Aid. However, this feature is not yet a year old and I do see customers starting to take advantage and enforcing additional business rules without a developer. I am very interested to see what capabilities might be added in the next year or two.

Thanks a lot for your wise answer. I will test it cautiously, and I will wait for the first feed-back in production on the first instances.

Interest in it is for me not only to avoid needing a devlopment team intervention, but also to avoid modification on a standard application, so the modification won't be impacted by subsequent ESU installation or new upgrade.

Kind Regards.

 

[Gustavo Barizon]

There's a ratio between volume (scale) and performance (how fast you need) that you can stretch. Still, needless to say, there are different scenarios in which you can use each type of tool, from writing a business function in C to improving a query in the database to an Orchestration running a Form Service Request and anything in between. It all depends on your judgment.

Of course, nothing impedes you from making a "hybrid" approach.

A couple of years ago, I had to create a UBE to "massage" the data and write in a table to make it available for user consumption. And you know what? I had to do the same for another client many years ago when a partner sold One View Reporting as a BI Tool.

We must understand what Orchestrator is, but most importantly, what Orchestrator ISN'T. It isn't an ETL or a data warehouse tool.

And here's where your judgment comes in. You must think at scale, with Production always in mind (volume - remember the ratio?), and ensure you can interface the data with the outside world. If it's an internal-only, mass data movement with many complexities in filtering and aggregations, there are better tools to use instead of Orchestrator. Of course, if there's that SQL to update some records in PROD, you can look to LEX to make the case, but common sense is good, even though you're an Orchestrator evangelist inside your business.

It's undoubtedly that Orchestrator brought a revolution in the JD Edwards arena. It's a real driver for digital transformation, especially now with AI. We're doing extensive research about the benefits of AI in the form of "OmniApps," where you can have answers to your questions, whether seeing what the POs you have to approve to specific batches are and their information. I notice the Orchestrator as a critical piece, but again, with all deserved reservation and paying attention to the ratio: scale x volume.