When developing a forms and workflow solution, you regular need to populate so called picklists (a.k.a. dropdowns). It 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 picklists rather than presenting free-text fields.
Often these picklists need to be populated with values from SAP. Driving 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.
In certain cases, it may be sufficient to essentially “hardcode” the list of values in the form itself. This option is mainly used for data that does not change, e.g. a list of salutes: Mr., Mrs., Miss, 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. This option is suitable when the values are not in SAP or because you want to define the list of values differently to what SAP does.
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 will utilize a SQL Server database as an intermediate storage for the values and schedule the Query scripts to regular export values from SAP and into the SQL Server database.
Using this option of 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. This approach is appropriate for most cases 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. This option is suitable for data where SAP is the system of record and where the values change frequently and irregularly. 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.
Questions or comments about this article?
Tweet @kalsing to continue the conversation!