cancel
Showing results for 
Search instead for 
Did you mean: 

How to test Process Dispatch Framework

ManuToivanen
Level 4
We are doing an automation between ServiceNow and Blue Prism. The goal is that ServiceNow calls (invokes) a process from BP using the Process Dispatch Framework. It seems that the user guide is made for a multi-authentication environment and our environment is configured for a single-authentication (Active Directory Single Sign-On). In addition to this our runtime resources are configured to use SSL certificate.

We have exposed this web service and we have tried to use a Postman to test it. It looks like we have problems at least with authentication. We haven't done this kind of things before and therefore it is possible that problem is between chair and keyboard... Is there something special what we have to take into account with our configuration/environment? The creation of user IDs / credentials is different at single-authentication environment than in multi-authentication environment. Does this have any impact? Can you provide us a little help and guidelines how to test this framework? @ewilson, any ideas?


​​​
6 REPLIES 6

ewilson
Staff
Staff
@ManuToivanen,

When you say you're set up for a single authentication environment, I assume that means you're set up for Active Directory authentication? To authenticate your request to the exposed VBO (Utility - Process Dispatcher), you use Basic HTTP Authentication in the request with username and password of the Active Directory user you are attempting to authenticate as. The username can be a number of different formats:
  • samaccountname (where it will look for the user in the domain specified in Blue Prism)
  • DOMAIN\samaccountname
  •  userprincipalname i.e. something@some.domain
Cheers,
Eric

ManuToivanen
Level 4

@ewilson,

Yes, we have set up Active Directory SSO authentication. We tested different username variations and UPN works just fine when we are using accounts which belongs to real users (like myself).  However, we cannot log in with corresponding service account even if we try the same way. There is probably something wrong with our service accounts which we tried to create following the Process Dispatch Framework - User Guide.​

We created a group for Web Service Consumers and joined a service account (BPwsConsumer) to this group. After this we added this group to BP System - Security - User roles. The corresponding service account was also added to the BP credentials​​ using the same user/account name and password. Does it matter that this service account is not part of BP System - Security - Users, because this information comes from Active Directory?

Can we use Postman to test this framework? If so, what kind of basic test scenario would be easy to create for this purpose? At the moment I feel that we don't have a clue what to do with this.

ewilson
Staff
Staff
When you say "service account" are you talking about an actual Windows service account like NETWORK SERVICE? If so, I don't think that will work. I believe it needs to be a user account. Something that could be used to actually log into the Interactive Client if you tried.

Cheers,
Eric

ManuToivanen
Level 4

@ewilson,

When I'm talking about service account I'm referring to BP Process Dispatch Framework -  User Guide:

3.2. Credentials
This framework utilizes credentials in three areas:
• Web Service Invocation
• AutomateC Execution
• Querying the Blue Prism Database

3.2.4. Credential Manager
The details of the various credentials, described above, must be stored in the Blue Prism Credential Manager. Use of Credential Manager allows the processes and VBOs of the dispatch framework to access the username and password in a secure manner without having to hardcode those values within the actual processes/VBOs. To add those credentials to Credential Manager, simply create a new General credential for each of the user accounts and populate the Username and Password with the account details. Within the various processes/VBOs of the framework simply reference the credential name where required. The processes/VBOs will then request access to the credential from Credential Manager.

Because we are using Active Directory SSO as a login method we can't create users directly from Blue Prism as the User Guide advice.  So, we have created separate accounts for Web Service Invocation, AutomateC Execution and Querying the Blue Prism Database to Active Directory and Web Service Invocation and AutomateC Excecution accounts has joined to Web Service and Runtime Resource group and after that these groups can be added under BP System-Security-User Roles. Account for querying database was created to SQL Server and read only DW01 -account was added to BP Credentials. Corresponding Web Service Invocation and AutomateC Execution -accounts were added to Credential Manager.

It would be nice if User Guide took into account that someone is using purely AD SSO.

ewilson
Staff
Staff
@ManuToivanen,

I'd recommend using SoapUI to test the framework. It has better support for working with Soap web services than Postman does in my experience. Within SoapUI, create a new Project and then enter the URL of the Process Dispatcher VBO's WSDL (eg. http://localhost:8181/ws/ProcessDispatcher?wsdl). From there you should see 4 available actions: CleanUp, GetProcessStatus, Initialise, and RunProcess. You can ignore CleanUp and Initialise unless you're trying to manually manage your bpInstance information (which I don't recommend).

Once you've got you project created, click on the RunProcess action and expand it. You should see a Request1 entry. Double click that to open to definition window. You'll see the Soap request envelope definition. You'll need to fill in some values. Here's an example of one of mine:

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:blueprism:webservice:processdispatcher">
   <soapenv:Header/>
   <soapenv:Body>
      <urn:RunProcess>
         <bpInstance xsi:type="xsd:string">auto</bpInstance>
         <UseSSO xsi:type="xsd:boolean">False</UseSSO>
         <BPCredentialName xsi:type="xsd:string">Blue Prism</BPCredentialName>
         <ProcessName xsi:type="xsd:string">CalcWSProcess</ProcessName>
         <ProcessParameters xsi:type="xsd:string"><![CDATA[<inputs><input name='taskId' type='Text' value='12345' /></inputs>]]></ProcessParameters>
         <CallbackInfo xsi:type="xsd:string">{'eventID': 3}</CallbackInfo>
         <ResourcePoolName xsi:type="xsd:string">DispatchedProcessPool</ResourcePoolName>
      </urn:RunProcess>
   </soapenv:Body>
</soapenv:Envelope>​

You'll want to set the following values:

  • bpInstance = auto
  • UseSSO = True
  • BPCredentialName = The name of the credential in Credential Manager to use to execute the specified process (this is the one that's passed to AutomateC)
  • ProcessName = The name of the Blue Prism process you want to execute
  • ProcessParameters = This is the XML input that you would pass to the process if it expects input. If it doesn't take any direct input, you can leave this as is.
  • CallbackInfo = If you have a service that will accept a callback post from the process, this is where you could specify any extra information you want passed back. Otherwise, leave blank.
  • ResourcePoolName = The name of the Blue Prism Resource Pool that should be used to execute the process.
You'll also need to enter the credentials for the HTTP Basic Authentication of the Soap request. You do that by clicking the Auth option at the bottom of the Request window:
34874.png
In the pop-up, you'll select Basic and then enter the username and password for calling the Soap service. After that, you should be able to press the Submit Request. If the request successful, you should see a response similar to this in the response window:
34875.png
Cheers,
Eric

ManuToivanen
Level 4
@ewilson,

Thank you very much for your help and effort!