I’ve been using this pattern for > 6 months now. It’s been working great for using SharePoint as a UI host and data host – which is itself a very productive pattern; you’ve got mediocre templates that DO work right out of the box (as opposed to NOT having them, this is a plus), the SharePoint designer is free to download and use, its fairly self explanatory, and you don’t have to stand up things like database servers and application tiers just for a small little project.
In Part 1, I shared the code I have that talks to SharePoint and discussed how it works. This is Part 2, where we’ll look at specific jobs in Automic (UC4) that consume the output of that code.
If you’ve read Part 1, you may recall that we created a Visual Studio .NET program to output a list to the command line, of the following format:
MyList;00000000001;jmccrack MyList;00000000002;jsmith MyList;00000000003;ggoblin MyList;00000000004;pparker
We also configured that same program to accept a parameter of “-mark ID” to set a Handled flag to true as each line item is performed. We’ll now configure a UC4 job to parse these results, perform the automation, and mark the SharePoint List as Handled=true for each item.
To parse the output, create a Windows Job Step in Automic. This job will serve as a scanning job that will poll the SharePoint list for changes. Configure with your appropriate AGENT and LOGIN values for where the utility from Part 1 will run. This can be any server that’s part of the domain where SharePoint runs and the LOGIN will need to have Read and Modify access to the list(s) you are automating against. While on the Attributes tab, you want to set Max Parallel to 1 with Abort as the option; this will prevent the scanner from being called while a previous run is finishing.
On the Process tab, call the utility you created in Part 1. The example I’m copying/pasting for this is for our MobileIron Enrollment process, so I named the utility “MobileIronEnrollment.exe”:
Then you need some simple script on your post-process tab to parse the columns:
: SET &HND#=PREP_PROCESS_REPORT("JOBS",,"REP","MyList*","COL=DELIMITER","DELIMITER=*;*") : PROCESS &HND# : SET &ID# = GET_PROCESS_LINE(&HND#, 2) : SET &USERNAME# = GET_PROCESS_LINE(&HND#, 3) : PUT_READ_BUFFER ID# = &ID# : PUT_READ_BUFFER USERNAME# = &USERNAME# : SET &ACTOBJ# = ACTIVATE_UC_OBJECT(INMAR.DO.MIENROLLMENT.SECURITY.PF,WAIT) : ENDPROCESS
Note the first line, where we’re filtering the output based on the listname we used in Part 1. You’ll want to adjust this if you changed the code in the String.Format call that outputs each item.
For each line, we parse the columns, insert the data into a READ_BUFFER and call the workflow that actually executes on the request. Create a new workflow. In the workflow, put the following code in to parse the parameters passed in
:BEGINREAD : READ &ID#,, : READ &USERNAME#,, :ENDREAD
You’ll also want to put those same Variables on the Variables and Prompts tab as follows:
With this configuration, you can use &ID# and &USERNAME# in the child jobs to complete the automation for the request.
As the final job step in this workflow, you’ll want a Windows Job Step that marks the request handled. Copy the scanning job you created to a new job and modify it in the following manner:
Then add the marking job to your workflow after the steps you’ll need to actually satisfy the request. If you setup a TIME EVENT to call the scanning step on a regular basis, that will finish the automation! The pattern is:
- Your event will call the scanning job every few minutes.
- The scanning job will execute your workflow for every line in the underlying SharePoint list that has Handled=false.
- The workflow will meet the request
- The final step of the workflow will set Handled=true on the SharePoint List.
Good luck and happy automating!