What role does custom coding and scripting play in orchestrations? While 90% of Orchestrator solutions can be created by business analysts, developers occasionally need to step in and lend a hand with calculations, date formatting, string manipulation, and more. Let’s take a look at where “getting Groovy” helps you accomplish what is needed when low/no-code doesn’t cut it.
Not familiar with Groovy yet? This is a scripting language with Java-like syntax for the Java platform. It simplifies the authoring of code by employing dot-separated notation, yet still supporting syntax to manipulate collections, Strings, and JavaBeans.
According to Oracle’s guide on the topic, “In the Orchestrator Studio, programmers can use Groovy to extend the functionality of orchestrations. The Orchestrator Studio provides an editing window for creating the Groovy script, so you do not have to use an external editor to create and test your custom program. The editing window contains a Groovy template that you can use to help get you started. Second, the Orchestrator includes the Groovy script natively as part of the orchestration, so you do not have to deploy a custom program like you do with custom Java. The Groovy script simply executes as part of the orchestration.”
Where Is Groovy Used in Orchestrations?
There are four areas where Groovy tends to be helpful as a workaround.
With custom requests, you can inject Groovy script that acts as a component in the orchestration. Business analysts can define the inputs and outputs they need, but everything that happens inside is a blackbox from their perspective.
Here’s an example where a custom request helped a client update advanced pricing in JDE. There was no Query By Example (QBE) row to locate records that matched specified criteria in a grid. So, we used Groovy to find and return the correct row based on our desired input values.
2. Connectors
Connectors are useful for accessing and interacting with non-JDE databases and with REST APIs. For databases, we use Groovy script to write and execute SQL so that we can read, insert, delete, or otherwise manage data. With a REST connector, we can manipulate the output returned from an API REST call.
3. Rules
The Orchestrator “rules” component can do basic conditional (if/then) logic. That’s fine for comparing two variables or a variable and a literal value. However, going beyond that is where things get difficult. If you want to mix and match variables with boolean logic, or do fuzzy searches, you need Groovy.
4. Orchestration Output
To see our presentation on Groovy and the Orchestrator, visit Quest.
The Orchestrator Is Catching up with Groovy
If you upgrade JDE to the most current version, you’ll find that the Orchestrator keeps adding more functionality. Sometimes, this means Groovy is no longer needed. In the earlier example of finding and updating rows in a grid without a QBE, Groovy script can now be replaced with a filter in the Form Request.
Another client wanted to do post-processing on the output of an orchestration, manipulate the output, and then use it as input for another API call. In newer versions of the Orchestrator, that’s no longer necessary either.
Should you replace Groovy when it’s no longer required? You can certainly leave the Groovy scripts in place and they will continue working. However, there is an advantage to ripping out this “black box” and streamlining the process to use only the Orchestrator. You can then transfer maintenance to the business analyst and relieve the burden on developers.
Are you stuck on an Orchestration integration or function? Get help fast with ACBM’s Orchestrator support.