Form Requests allow you to work with any interactive application in JDE, including both standard and custom apps. This versatility makes it a highly useful component for users who are developing their own integrations and process automations. Form requests exactly replicate the steps a user would perform manually.
For example, to add a new address book record, the form request comes into the application, clicks the add button, fills out the fields with the desired data, and clicks the save button. You can think of a form request as a robot version of a user that does your bidding. Just tell it what steps to do and the order of the steps. When you push the button, it does everything you’ve asked.
Let’s Take a Look at Building a New Form Request
Available Actions
When you start creating a new form request, it automatically pulls up available actions. Every possible action you can perform in the application is available including all the fields on all the tabs (even buttons and exits such as OK and cancel). If there is a grid in the application, all that information is available too and you can use Query by Example (QBE) for filtering.
Inputs and Values
Within each of the available fields, you can decide whether to pass information in at runtime as an input (a variable from the orchestrator or a previous step) or a hard coded default value. You can fill out one or the other, or both.
One trick most people don’t know is that you can concatenate or join two things together such as having two inputs or a literal value and an input value. You can use text substitution to add commands. For example, if you want to designate Address Line 4 as an Attention line, you can concatenate literal text and a parameter name (in ${ }). For example:
ATTN: ${Attention Name} .
Want more information about ACBM Solution's Orchestrator Training? Get a Free Sample Chapter from our Training Manual and Start Learning Today!
Why Don’t Form Requests Ever Break?
One of the best things about form requests is that they are unbreakable. Unlike other pieces of an orchestration that might stop working after an upgrade or changes to the tool or app, the form requests keep right on doing what you originally told them to do. They still work even if you change the outputs, structure, and syntax.
Form requests stay consistent in their performance because of the AIS ID number. Each available action in your forms request screen has a unique ID assigned to it. If you go to the JDE web application and click on an action field look at the advanced help section, you will see the exact same ID listed there.
What’s in the front end is linked directly to what’s in the studio. The combination of that particular application form and the unique ID # associated with that field in that form keeps everything in sync. Even if you change the field description using Form Personalization or Vocabulary Overrides, it will still pull the same field information because JDE is using the AIS ID # which never changes.
The form request subcomponent is the foundation of virtually every orchestration. It allows you to add or update data anywhere in JDE. Popular use cases include Sales Orders, Journal Entries, Parts, or really any application in JDE.
Find out more about our Orchestrator training. Download a Sample Chapter from our Orchestrator Training Manual.
Next, let’s take a look at Rules. This is the subcomponent that allows you to add more logic that makes orchestrations more useful and powerful.