4 minute read BPS Version: 2020.1.3.411


This post describes an SDK Custom Action which populates an item list with data read from an XML attachment. If you are interested in one of the following topics read on:

  • Creating a plugin configuration with a grid
  • Reading an attachment
  • Populating an item list
  • Logging to admin view in history
  • Tips for Debugging and VS build events

Initial Situation

Even today you will find yourself in a situation where you receive a plain xml file which needs to be processed. Let’s assume that it contains invoice information. The xml file will be part of a mail along with other attachments. Someone from purchase receives this “invoice” and starts the invoice workflow from Outlook add-in by dragging the mail on the start tile (1). In the new workflow he drags the attachments from the mail on the attachment control in the browser (2). The result will be a new invoice instance with prepopulated fields (3), the attachments (4) and the e-mail (5).

Starting a workflow from Outlook
Starting a workflow from Outlook

In the next step he selects the Xml file (1) with the invoice data and send the workflow to the next person. During the transition to the next person the Xml data should be read into an item list (2).

Item list is populated from selected XML file
Item list is populated from selected XML file
Source xml
Source xml

Workflow artifacts

Attachment picker

The attachment picker uses a simple sql query fetching all xml attachments of the current workflow instance (1) and defines an “Empty element display name” to prevent automatic population of the field with the first available value.

Definition of attachment picker
Definition of attachment picker
SELECT [ATT_ID] as Id, ATT_Name as Label
FROM [dbo].[WFDataAttachmets]
where ATT_WFDID = {WFD_ID}
and [ATT_IsDeleted] = 0
and [ATT_FileType] = '.xml'

Xml to item list action

The action used for populating the item list is called “XmltoItemList”.

Custom action XMLtoItemList is selected from plugin CC_XmlToItemList
Custom action XMLtoItemList is selected from plugin CC_XmlToItemList

It expects a picker which identifies the XML file which should be used (1). The structure of each xml will be different. Therefore, the custom action uses an XPath to select the rows which should be processed (2). This allows a high flexibility. The nodes of each matched row will be processed to create new rows in the selected item list (3). The values are retrieved from the inner text of the xml node and note from attributes, which don’t exist in the used sample.xml. For each node a type must be defined, so that the custom action transforms the xml text to a corresponding WEBCON BPS value. All values in the configuration taken from the Objects register and not from the Values register.

Configuration of the custom action
Configuration of the custom action

Workflow history

In the workflow history the normal user view does not contain any additional information. Every created row is visible to the user anyway. But if you are switching to the admin view, you will get additional details.

In admin view additional details are visible
In admin view additional details are visible

VS Solution information


The logging is done using a simple StringWriter class which uses manual indentation.

logger.Log($"Populating item list");

The log messages are displayed in admin view only because the log string is assigned to the LogMessage property

args.LogMessage = logger.ToString();

Build event usage

The solution makes use of the pre-build and post-build event. The pre-build event uses a PS script to increase the revision number of the solution. The post build event creates a .zip package and copies it to the development BPS server.

Build output where the field has been copied to
Build output where the field has been copied to

The reason for this is, that no development takes place on the BPS server. Therefore, the combination of the pre- and post-build events will allow me to “immediately” upload a new version of the plugin package in BPS. Yes, I still use the server side BPS Studio.


Debugging a solution requires to attach Visual Studio to the BPS Portal process. If you upload you plugin multiple times without recycling the process you will notice that you assembly has been loaded multiple times. If Visual Studio tells you that no module information have been loaded and you are sure that you uploaded the latest build version, a good option is to recycle the process.

While debugging: Loaded modules by the process
While debugging: Loaded modules by the process

Remark: Be sure that you inform all your colleagues if you debug the process on the dev server. Otherwise, you may find yourself in an unwanted situation. :)


The custom action solution can be download from:


Fun facts

The post has been born from these two community questions:

SDK configuration with a dynamic grid

Attachment file handle with SDK

All in all it took three hours:

Actions Proof
Solution for custom action created at 19:49
Sample process created at 20:47
Started Blog post  
Setting up Outlook  
Last change to sample process 21:51 See above
Repository created for custom action 22:48
Blog published 22:53