IBM Business Automation Workflow Adding Automatic Data Refresh to A View

A quick guide to adding a auto-refresh script in your coach view.

Authors: Leonard Blunt , Greg Ekaprana, Okka Sudaryanto, Diorella Mari Tom

Code Repository

Deferred Section Example is in the Tips for BAW Toolkit in github.

Introduction

We have found that there are times when a business group or unit may have a view that they want to automatically refresh, the requirement is common enough and as such we will share the basic scripts to quickly accomplish this.

In this example we will focus on refreshing of data for a section of view. Using a simplified example of a pattern we called a preset filter which was implemented in a recent project.

So, let’s start by setting a business context on what a preset filter was and how they were applied. In the scenario we were working with a number of steps in the workflow that were event driven with activities happening as swivel chair outside of the main process flow, users who conducted the external activities would update a data into a dashboard which would sometimes trigger process events. With this interactive dashboard established the preset filter was a way for the user to infer a business state and quickly limit the records in the dashboard to the filtered business state.

The filter was often inferred my multiple data fields and was part of a large dataset which is why standard table capabilities were not used to meet the requirement. 

For example, states such as “Wait-Document-From-Client”, ‘“Pending-Internal-Document-Signing”. The business needed the filter links to show the user the number of records in that state much like an email inbox or badges on a mobile app. This requirement is what actually led to the need for the refresh to periodically update the counts on these filters as the dashboard pages was the main working area for these workers and they rarely navigated to other views.

We will use this scenario to setup and demonstrate the auto refresh. The business data and service flows will be significantly simplified to retain focus on the refresh, which of course can be used for a great many other reasons.

Example Adding Auto-Refresh to The Preset Filter

We have developed a simple data UI showing records in a table with a filter selectable above the table.

The business scenario we mocked up here was a list of products and their current inventory count and status. You can imagine that their status gets set based on rules implemented in the back end based on historic consumption rates. We have set it up to work with four basic status, In Stock, Reordered, Out of Stock, and At Risk. In this simple scenario let’s assume that when reordered the user has an out of system activity to check delivery date if not received 1 week after ordering, and an out of system activity to Reorder out of Stock, or At Risk items.

Please take note to highlight the auto refresh the service flow "getProductListStatus" was set up to always return a different result set altering the count of records meeting the filtering criteria.

We commence with the baseline of the simple data table and filter as described already configured and working. This is illustrated in Figure 1 “Auto Refresh Example” Dashboard. In this view, we see the table data the filters being shown which tell us how many products are ready for reorder and how many need their delivery date checked.

Figure 1 Table and Preset Filter without Auto Refresh.

As discussed, the user scenario is that this dashboard is the workspace for the team assigned, so as product orders are processed the number of items to reorder and items to be checked for delivery will change over the day. To assist the user, we will add an auto-refresh to the view.

When running the toolkit demonstration, a version of the coach view exists that does not have the refresh yet applied. You can switch the CSHS to this view if you want to run and execute without the refresh applied. Use StockDashboard coach view.

Determine the features of the Refresh

When adding refresh to a UI section or page we typically include three main features

1. Ability to disable Auto-Refresh (typically defaults enabled)
2. Ability to change the refresh interval
3. Ability to manually refresh and not wait for the auto refresh

For the purposes of this example we will implement all three of the above.

This is done by opening the coach view. The auto refresh functions are for the filter counters as this is the case, we will place the refresh within this section of the view.

This view is inside a deferred section that has visibility set to None. When editing the view set the visibility to hidden. And change back when completed.

Figure 2 The UI components of the Auto Refresh

If looking to use the scripts that will follow the UI components should be given the following control ids

• CheckBox = autorefreshCheckbox
• Interval Label = autorefreshIntLabel
• Integer = autorefreshInt
• Icon = autorefreshIcon

Having added the UI components, we can now add the java script functions to support the auto refresh in the inline JavaScript. The auto refresh scripts have been uploaded to the git repository here.

This code is also a good candidate to extract to a script library, except for the refresh function which will need to be unique for each use.

There are 5 functions that have perform the auto refresh and some global variables to keep track of the current state within the view.

initAutoRefresh() Function

The initAutoRefresh function sets the default check box value and the default interval for the automatic refresh. In our example, refresh sits inside a deferred section. This means that the init must only be called once that section is loaded. As a result, the showHideFilters (Figure 5) adds a call to the initAutoRefreshFunction. But we only want the function to init one time and the showHideFilters can be invoked many times as such Line 14 ensures init functions only execute once.

Figure 3 Auto refresh Global Variables

Figure 4 initAutoRefresh function

Figure 5 showHideFitlers Function

setAutoRefresh() Function

The setAutoRefresh function sets the values for the interval and if the auto refresh is enabled calls the startAutoRefresh function.

• The function checks that the minimum interval that can be set is 1 minute.
• In the case that it is disabled the UI components for the interval and the manual refresh are hidden.
• When this function is called if auto refresh was already started the currently running script is stopped in preparation for the changed configurations. The Interval id returned when the auto refresh initiated must be used as a reference key to stop the initial configuration.
• Once finalized if the auto refresh was not turned off then the startAutoRefresh function will be called.

Figure 6 setAutoRefresh function

startAutoRefresh() Function

The start auto refresh sets the callback function and the interval using the JavaScript setInterval function, sets the active tracking variable to true and returns the tracking id.

Figure 7 startAutoRefresh Function

stopAutoRefresh Function

Clears the interval using the id returned from the stop and sets the active tracking variable to false.

Figure 8 stopAutoRefresh Function

refresh Function

This function is key to executing the refresh. Each time this is setup what you want to do in the refresh will change. But by using this wrapper function the startAutoRefresh does not need to be changed all the time to alter the callback function. In our example in the refresh function we call the getCounts functions which invokes the service call and triggers the refresh of the filter information displayed.

Figure 9 refresh Function

Final Steps

With the functions in place the final sets is to add calls to the functions from the auto refresh UI components

• Checkbox — onChange event
• Integer — onChange event

view.setAutoRefresh();

• Icon — onClick Event

view.refresh();

Summary

In summary with any view that may need some automatic refresh you can quickly setup the capability and utilize these reusable scripts. The toolkit includes the completed working code as well as the incomplete coach view that you can copy to quickly recreate this work here. Shown in Figure 10 is the UI with the logging enabled in the developer console showing the calls to alter the timing and then the calls to get the data.

Figure 10 Filter Counts Auto-refreshed

1. Shows the logging in the init stage followed by the result from the initial service call that is part of the data load
2. Shows the change or refresh interval to 1 min. Then the subsequent refresh which retrieved the new result.