Populate picklists in forms

When developing a form and workflow solution, you often need to populate drop down menus (sometimes called 'picklists'). This is a common task when developing forms with Winshuttle Workflow where you are typically collecting data for SAP.

A key requirement in most scenarios where data is collected for SAP is to guide the user through inputting the right values. This can be achieved by limiting the user's choice with drop downs rather than presenting free-text fields.

Often these dropdown menus need to be populated with values from SAP. Getting values directly from SAP means less maintenance on the form as changes in SAP will automatically be reflected in the form. In other cases, you may need to manually maintain the list of values because either the field is not in SAP or because you want to define the list of values differently to what SAP does.

When you build forms and workflow solutions with the Winshuttle Usability Platform there are essentially four options for populating picklists, two options for automatically keeping the values in sync with SAP and two options for manually maintaining the list of values.

Four options are outlined below with common usage examples.

Static values

In certain cases, it may be sufficient to essentially "hardcode" the list of values in the form itself. These lists are usually lists that will never (or only very rarely) change.

Common use cases
  • Data that does not change, e.g. a list of salutes: Mr., Mrs., Miss, etc.
  • List of months or states in a country (i.e. Jan, Feb, etc.)

Business maintained values

Like the static values described above, the values are not driven by SAP. But rather than being a static list, the values can be maintained by a business user. Essentially the form will utilize standard SharePoint lists as the data source for populating a picklist. SharePoint lists provide business users with a web-based interface for maintaining these values manually. Whenever an admin user in the business updates the list of values in SharePoint, it will automatically be reflected in the picklist on the form.

Cached SAP values

There are two supported options for picklists where the list of values is driven by SAP, cached SAP values and live SAP values. In both instances you will use Winshuttle Query to author a query that extracts the values from tables in SAP. When using cached SAP values you can utilize a SQL Server database or a SharePoint list as an intermediate storage for the values and schedule the Query scripts to regular export values from SAP and into the SQL Server database or SharePoint list. Additionally, there is also an option to utilize the native caching functionality of Server.

Using an option for cached SAP values, you reap the benefits of driving your picklists from SAP without putting unnecessary strain on the SAP system. Your form will also perform better compared to using live SAP values as described below.

Common use cases
  • Data where SAP is the system of record, e.g. company codes, functional locations, etc.

Live SAP values

In instances where you require the picklist to populate directly from SAP by executing the query when the form loads, this can be achieved by wiring a picklist directly to a Query web service. This can, however, have performance implications on the form. If there are many such picklists on the form, it may take up to 15-30 seconds to load. For use cases with many users, it also means that the SAP system has to serve the same query frequently. In reality, it is rarely required for a picklist to be live to SAP. For SAP-driven values, the above option of cached SAP values is usually the preferred option.

If live queries are required, they should be limited and constrained. Limited in number and constrained in that end users should be able to provide some intelligent filter to cut the number of items being returned to the form.

Common use cases
  • Data where SAP is the system of record and where the values change frequently and irregularly.