Custom Requests provide a way to insert more complex logic and functionality into orchestrations. This is where the low-code aspect of Orchestrator comes into play with the use of programming languages like Groovy to add custom scripts. However, there is also a no-code way for users to create Custom Requests via business functions.
Using Groovy Script for Custom Requests
By writing Groovy script inside a Custom Request, you can define input data and output data (returning variables or even an array). Developers often use GS in Orchestrator for complex calculations, date formatting, and string manipulation. For instance, you can build a custom request to locate and return the correct row from a grid without a Query By Example (QBE) row.
Groovy vs. Java for Custom Requests
For developers who are more comfortable working with Java, Orchestrator provides this language as an option. In practice, it’s rarely used because anything you can do in Java, you can do in a Groovy script instead (since Groovy is a superset of Java). Groovy can be written directly in the component, making it more dynamic and easier to maintain. In addition, there are many Groovy libraries that make it easy to do things like manipulating JSON, executing SQL, etc.
If you do use Java, you must develop and compile your code outside of Orchestrator, manually move the class files to the AIS server where the orchestrations run, then put a link to your compiled Java code. Inside the Orchestrator Studio, there is no way to maintain or update Java. Java might be preferable as a way to protect proprietary code from other users, but otherwise there is no functional reason to use it.
Note about tools release 9.2.5.4: Oracle has released two other options, JRuby and Jython, for developers who are proficient in those programming languages.
Building Custom Requests with Business Functions
This is the no-code option for creating Custom Requests. In essence, you are calling a specific function from an existing JDE application. While an application calls many business functions in concert to deliver a working result, you can pull out just the one business function you need to plug into an orchestration component. In this way, a business function is much like a microservice, sitting between the application layer and the database.
You simply define the business function you want, select the name, and choose from the list of all the inputs and outputs associated with that function.
There are pros and cons to using a business function vs. the full application. Usually, it’s best to call an application using a form request. This approach gives you the benefit of all the data validation and security that’s built into the application. By selecting a single business function, you bypass these layers of safety. However, you do gain speed. This can boost performance for the custom request you are using in the orchestration.
Stay tuned! Next time, we’ll cover Messages and Notifications.
