User Context Types and Options

Overview

To make Rest or SOAP calls to Decisions it is important to know how to use User Context in the call. User Context is a required part of the service call to Decisions.

This tutorial demonstrates different User Context types in Decisions and best practices on how to use User Context in Rest and SOAP calls to Decisions.

Example

In this example, we are going to create a simple Flow and a Service for this flow.

Begin with creating a flow by clicking Create Flow

In the resulting dialog window Name the Flow and click Create to proceed to the Flow Designer.

In the Flow Designer, connect the Start step to the End step.

Then click Show Editor from the End Step.

In the Add Data resulting window click Pick from flow data link.

Then, expand the Flow Data and pick CurrentUserEmail.

Click Close to close the Data Definitions window.

Next, in the Flow Settings > Service Settings check the Create Service check-box.

Save and close.

Back in the Designer Folder, a pop-up Notification should display that states that Service was created for the flow.

In the Designer Folder, locate a thumbnail for the flow and from the Action menu select Run [Advanced] > Integration > View Integration Details.

Integration Details

The Integration Details Page will open in a new window.

On the integrations page in Display Type select REST. Different User Context types are available in the Credential row.

If we use Login as a Credential option, System will generate a URL with no User Context and when we will make a call with this URL, we will be redirected to the Decisions Login page if we are currently not logged in.

In the Credential row, select UserID/PW. Then we fill in User Id and Password text-boxes and click Show Service API. The system generates URL for us with userId and password parameters that have credentials provided by us.

This is not the safest way of Rest Service call because our credentials are not encrypted.

We can make a Rest call with this URL and see an XML output from the flow

Next, select the Named Session(list) Credential option, select Named Session from the dropdown, and click the Show Service API button.

Named Sessions can be created in the Decisions for different users and groups and be used as User Context.

Also, using Named Session Id is the most recommended type of User Context to use for service calls. The system generates a URL that has a sessionid parameter with a value that refers to our selected Named Session.

If we make a Rest call using this URL, we will see an XML output of the flow.

Because we used System Named Session, the flow outputs system email as Current User Email.

Next, select Guest as an option for the Credential and click Show Service API button.

This option will only work if Guest User is enabled in the Portal Settings and have the permissions to View and Use this flow.

The system generates a URL with the Guest parameter that is set to true.

If we make Rest call with this URL, we can see an XML output of the flow with Guest as a Current User Email Address.

Next, on the View Integration Details page select the Webservice option for the Display Type setting. We do not have an option to set Credential configurations.

The system generates Integration information for us on how to add Webservice reference in our custom code.

We are going to overview different User Context types using Webservice reference in Visual Studio.

If we want to make a service call to Decisions, we are going to need some type of User Context.

Let’s overview User Context object types that can be used for Webservice call.

First one is PasswordCredentialsUserContext.

In our code, we create a new object of this type. This object has UserID and Password properties.

If we set values for these properties, we can use this object as User Context to run our Flow.

This is equal to the UserID/PW option for the Credential setting that we used previously for the Rest calls.

Then, we can create a SessionUserContext object that has SessionValue string property. We need to set this property to the Named Session Id to use this object as User Context. This option will be the same as Named Session (list) Credential option for the Rest calls.

Another option is to use SecuredUserContext object with SecuredKey property.

If a Guest user is enabled in the Portal and has permissions to use and view this flow, we can use GuestUserContext object as User Context for Run Flow method.

Next, we are going to test how our User Context types work.  Before we run the flow, we need to create a Client with Http Binding and open this client.

Then, we create an object of our Flow Results type and set it using the RunFlow method using our client. RunDemoFlow method requires User Context input.

We use our PasswordCredentialsUserContext as User Context first.

Finally, we are going to output to the Console a Value of the first Data Pair.

If we run this application, we will see admin@decisions.com Current User Email Address output in the Console, because we used admin@decisions.com user credentials.

Then, we change User Context input to the Run Flow method to the SessionUserContext object in code and run the program

This time we should see system@mycompany.com Current User Email Address output to the Console because we used System Named Session Id.

Finally, change User Context input to the Run Flow method to our GuestUserContext and run our Program.

Because the Guest user in the system does not have an email, we have Guest as an output to the Console from the flow.