Workflow loader allows you to define your data source for work queue messages using a Sequential Workflow.
WORK QUEUE CLASS
You can define any work queue class you want as long as the workflow returns data in the right format (satisfies work queue class input mappings).
1. CREATE A LOADER WORKFLOW
To create a workflow that can act as a work queue loader you need to create a new sequential workflow and inherit from a predefined IWorkQueueLoader workflow stub.
IWorkQueueLoader contains the following context stores:
| Attribute | Description |
|---|---|
| attachments | Records returned here will be used as the work queue message’s attachments. |
| lastState | An input parameter which gives you information about the state when the workflow ran last time. You can use it to filter data based on the last execution. See resultState below. |
| resultState | A string returned here will be used as the last state in the work queue. It will be passed as a lastState on the next run. You can store e.g. id of the last loaded record or a time the workflow was last executed. Then next time you will use this value to e.g. filter the records to be loaded incrementally from the data source. |
| userName | User name from the work queue configuration that you can use to authenticate to a foreign data source. |
| password | Password from the work queue configuration that you can use to authenticate to a foreign data source. |
| other | You can define more input context stores. By using constant values defined in a work queue configuration connection string you can parametrize the workflow. |
The workflow must include one more context store (by your definition) that will be marked as IsReturnValue=True. This context store should return the messages.
If the work queue is based on an entity (Entity attribute is filled) then the resulting data are expected to be in the following format:
<ROOT>
<EntityName Id="111-111-111..." Field1="value1"/>
<EntityName Id="222-222-222..." Field1="value2"/>
</ROOT>
That means you should return the records as if they were stored in the database using the entity structure. Every record will produce a separate message.
If the work queue is not based on an entity (Entity attribute is empty) each node under the root xml node will result in a separate message.
Please note that the mapping under the work queue will be used to map values from each node to the work queue message.
Don’t forget to define your loader in the work queue class, otherwise work queue will complain, that you can’t you’ve specified an unknown loader.
2. CONFIGURE WORK QUEUE
To run your workflow periodically to generate messages you have to fill the External Source field with Workflow on tab Creation and fill Connection String as described later.
3. CONFIGURE CONNECTION STRING
The connection string can consist of the following parts:
| Attribute | Description |
|---|---|
| name | Name of the loader defined under the work queue class in the model. |
| other | You can define an unlimited number of key-value pairs. The key will be a context store defined in the underlying sequential workflow. The value will be a constant text passed to the workflow. |
4. CONFIGURE USER NAME AND PASSWORD
Enter the account’s username and password to the corresponding fields in case the workflow makes use of them.