Page History

...

Method 3 - Workflow Process

...

with JSON Tool

With what we have learned so far, there's still 1 con that we are trying to solve. Let's try to put the form within a process flow in a diagram as below.

...

Method 4 - Form Validator and Form Store Binder

Triggering the JSON call from these 2 plugin types are not feasible but we will explain as part of knowledge sharing.

As the JSON Tool plugin is not a form validator nor form store binder type of plugin, we will need to use the workaround shared earlier, which is writing the bean shell code from scratch or calling the JSON Tool plugin programmatically.

Why Form Validator?

Form Validator Plugin expects a true/false to be returned. We may try to avoid the need of designing a process flow and achieve the same JSON result checking by making the JSON call through the validator plugin. The problem that would arise from this appraoch are:-

1. Same form content may get submitted repetitively as other form fields' validators may kick in too (i.e. mandatory field checking).
2. If the external API system becomes unresponsive, the Joget app will stop working.
3. Increased wait time. Response time includes JSON Tool's turnaround time.

Why Form Store Binder?

To avoid calling the API repetitively, let's move down to the next layer, store binder.

By calling the JSON API within the Form Store Binder Plugin, we will need to explore on how to handle events such as when JSON API is not being responsive. In this type of plugin, it won't be expecting a true/false to be returned like the validator plugin though.

We can try to throw an exception instead in the Bean Shell code that we are writing.

Image Added

Figure 12

This approach suffers from the following issues:-

1. If the external API system becomes unresponsive, the Joget app will stop working.
2. Error message is not friendly.
3. Increased wait time. Response time includes JSON Tool's turnaround time.

Method 5