User Context Types and Options

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. Then, we will explain different User Context types and how to use them.

We begin in the Designer Folder with clicking Create Flow on the Folder Actions Panel.

In the resulting pop-up window we Name the Flow and click Create to proceed to the Flow Designer.

In the Flow Designer we simply connect Start step to the End step on the workspace and click Add New Data Output for the End Step.

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

Then, we expand Flow Data and pick CurrentUserEmail. Click Ok when finished.

Click Ok to close Add Data window.

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

Then, we Save our Flow and close Flow Designer. Back in the Designer Folder we should see a pop-up Notification that says that Service was created for our Flow.

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

Note:

Integration Details Page opens in a new window…

First, we are going to overview User Context use in Rest calls. On the integrations page in Display Type we 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 we select UserID/PW. Then we fill in User Id and Password text-boxes and click Show Service API. System generates URL for us with userId and password parameters that have credentials provided by us. Mention, that 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 our Flow…

Next, we select Named Session(list) Credential option, select Named Session from the dropdown, and click 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. System generates a URL that has 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 our Flow. Because we used System Named Session, our Flow outputs system email as Current User Email.

Next, we 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. System generates a URL with Guest parameter that is set to true.

If we make Rest call with this URL, we can see an XML output of our Flow with GUEST as a Current User Email Address.

Then we select last Current User Authentication option for the Credential setting and click Show Service API button. With this option System encrypts current user credentials into a String and passes it into the URL as a value for the authid parameter. This type of User Context is good to use when we want users to make service calls with our current Permissions.

When we make a call using generated URL, we should see a Flow outcome with our Current User Email Address.

Next, on the View Integration Details page we select Webservice option for the Display Type setting. Mention, that we do not have an option to set Credential configurations. 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.

For this example we create a simple Console application and add Service reference to the project using the Address that was generated by the System.

Like we explained previously in this tutorial, 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. Mention, that this object has UserID and Password properties.

If we set values for this 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 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 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 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, we change User Context input to the Run Flow method to our GuestUserContext and run our Program…

Because Guest user in the system does not have an Email, we have GUEST as an output to the Console from our Flow.

Additional Resources

• Integrating Decisions with External Oracle Database