Workflow and ServiceDesk Community

This article will cover the method I use to present a progress bar in my Workflow forms.

Here's a quick screencast of the project:

There are a few important points to understand:

• When monitoring a repeating process in form, a good practice is to leverage a separate project to do the repeating work
• By using an iframe component to display the UI of the separate project, we can handle exceptions and other issues gracefully while remaining in the main interface
• We can make javascript calls between the iframe and its parent

So into the exciting details we go.

I've attached two demo projects.  The first is the iframes project, which will need to be published first.
The second is the main frame project and will be published second.  Prior to publishing this project, however, take note of the URL of the iframes project, and update the URL property in the main project's properties section:

After ensuring the IframeURL property has been configured properly and both projects are published, the demo should work as intended.  I'll go into a bit more detail about how and why this works.

Let's start with the "Parent" form.

The parent form process for this demo is very simple on the Workflow canvas.  The only things we're doing in the "Data" embedded rule model are:

• Initializing (Declaring) variables
  • FormCSS text
  • LoaderCSS text
• Creating the value for the FormCSS variable (CSS for the main elements on the forms)
• Creating the value for the LoaderCSS variable (the loading spinner used during load/wait times)
• Creating the value for the IframeURL variable (the "IframeURL" project propery supplied in the section illustrated above is not available in all areas of the project, so we'll merge it down to a canvas-level variable to ensure it's always available to use)
• Exception handling

On the Form Builder component "Parent Form", pay close attention to the CSS styles given to each element.  Note the 20x20 "IncludeHTML" component at the top of the form; this component holds the "FormCSS" value and applies our styles at runtime.

Some good Form Builder best-practice items to build habits for:

• Provide unique Control Ids for every element
• Avoid FOUC (see here) by providing onload scripts
• Provide CSS for your forms before styling inline (when possible)

So, back to the Parent form.  As we can see in the illustration above, the Iframe (at design time) will reside in some section on our page that we intend to have refresh separately from the main form.  The "buttons" on the left (Demo Config, Demo Date, etc) will be redirecting the Iframe location/URL using javascript configured in the page's Behavior section (double-click any blank part of the Form Builder canvas).  The Iframe component contains no URL; this value will be provided at runtime by the javascript in the other project.

Note the components overlaying the Iframe component on the bottom right (the component with the red X).  These components are our "progress" indicators, and start out hidden. The content and visibility of these components will be determined by the javascript embedded in the child project (the project called in the Iframe).

Over on the "Child" project side, for this demo, we are simply looping through words in a big block of hard-coded text.  This is so we can see the progress the workflow is making through an array, and to help visualize the progress bar.

The important part of this happens on the "Loader" form at the bottom right of the screenshot above.  On this page, we are updating the parent elements with the new progress data.  The concept regarding adjustments to an Iframe's parent can be found in more detail here.

At runtime, the form renders as such:

And clicking the "Run Progress Bar" demo button begins the loop which updates the parent form, making the progress elements visible and updating the text as well as the color fill of the progress bar.

The reason we use this method instead of just displaying the results in the Iframed project form is so the form doesn't refresh each time it exits and reloads.  The actual child form in the final screenshot above is simply blank, and exiting itself on page load.

Finally, when the processing is complete, the next form needs to set visibility=hidden on all the progress elements so they aren't still overlaying the child Iframe form.

This is a lot to take in from simply reading the text; check out the demo projects to see it in action, and as always, reach out with any questions!