CRM 2013 – Leveraging Actions to get around JavaScript cross-domain challenges

Last year, I wrote about the challenge of cross-domain calls from JavaScript with CRM 2011. The issue was related to fact that from a security perspective, you could not have JavaScript functions executing on a CRM form event or when a ribbon button is clicked calling web services outside of the CRM domain. I proposed a few workarounds here but the bottom line is that in all cases, there was some sort of a negative impact in each solution. With CRM 2013, actions processes are a great way to get around the browsers’ cross domain restriction.

In this article, I am providing an example of how actions can be used to make a request to a web service outside of the CRM domain from a record’s form event.

Scenario

When users call an incident management center, the agents need to capture the temperature at the time of the incident in the city where it occurred. In order to do so, we decide to create a button on the command bar that agents can click on and that will perform the following tasks:

  • Read the City and Country information from the form
  • Call an Action that
    • Takes the City and Country as parameters
    • Use an external web service to get the temperature in the city
    • Returns the temperature as output parameters
  • Sets the temperature field value on the form

Note: In order to achieve this directly with JavaScript, performing Step 2 of the action would require to make a cross-domain call from JavaScript.

Process Configuration

To start things off, let’s start be creating an Action of type process. This action will have 2 input values (City and Country) and 2 output values (Temperature in Fahrenheit and in Celsius).

The steps are really simple. The action needs to a custom workflow activity that will connect to a weather web service and return the temperature in two output values of its own.

Custom Workflow Activity

Here you can see what the custom workflow activity code looks like. It’s very straight forward in that it only has 3 steps:

  1. Read the city and country inputs
  2. Initialize the web service client object and make the web service call
  3. Set the values back in the output fields to be available in the process

Calling Action from JavaScript

This is the last piece of the puzzle. At this point, we simply need to call the action created from a JavaScript event (ribbon button clicked, on change of a value etc.). In order to achieve this, create a function that is called when the client even occurs. That function should execute the Action, read the output values and set the field values on the form. This has to be done with a SOAP call. There are two ways to do this. You can:

  • use Deepak’s example as show in his blog post here or
  • use the CRM 2013 Sdk.Soap.js action message generator published by the Microsoft CRM SDK team to generate a request and response class you can use in your call to call the action using JavaScript.

Wrap up

This is another great example of how actions can be leveraged to work around challenges that we’ve dealt with in the pre-CRM 2013 era. Keep in mind that in order to call an external web service from the custom workflow activity, there are server security elements to take into consideration (e.g. can my server talk to the web service? etc.)

Hope this helps!

Advertisements

CRM 2013 – Real Time Workflows

In the CRM 4.0 and 2011 days, I remember multiple times when I had to write plugins do to operations that a simple workflow could do just because it needed to happen synchronously. Microsoft brought a solution to that concern with the latest CRM 2013 release by introducing real-time workflows.

In order to create an asynchronous workflow, you simply need to create a workflow and uncheck the “Run this workflow in the background (recommended)” checkbox.

If you have missed it or are trying to covert an Asynchronous workflow into a synchronous one, you can do it by deactivating the workflow and using the “Convert to real-time workflow” button.

The workflows’ contents are the same. There is no additional operation that you can do in real-time. The one thing that changes is the way you set up when the workflow gets triggered. Just like when plugins are registered, you have the possibility to choose if you want them to execute before or after a specific event:

Background Process Real Time Process

A few key notes on Real-Time Processes:

  • They can run
    • After record creation
    • Before or after a record update, assignment or status change
    • Before record deletion
  • They can be set to run as the owner of the workflow or as the person making changes to the record in CRM

It certainly gives us more flexibility when it comes to designing feature for real day to day usage. One thing still makes me wonder… Microsoft seems to recommend using background processes. Assuming the reason for that recommendation is performance, I guess it is a way to let application designers know that even though workflows can be run in real-time, this should only be used when really needed as opposed to making it a standard and clogging the CRM Server. To be confirmed…

Cheers

Why Integrate Dynamics CRM with BPM Tools?

I came across this article a few days ago about integration between Dynamics CRM and Business Process Management (BPM) tools. As much as I believe there is a case to be made on integration between CRM and BPM tools, I felt like the examples/scenario presented in that article weren’t strong enough.

For example, if we take the scenario were “once a lead record has been created, it is assigned to the appropriate owner on the sales team, and that person can take the necessary steps to nurture the lead towards an opportunity“, it is simple enough to be handled directly in Dynamics CRM. Same for a case management solution, when a “case has been created in Dynamics CRM with all of its details,” how do we “ensure that the proper support team member receives it, handles it according to defined steps, possibly escalates it, and ensures that it is completed accurately in an optimal manner?“. From these simple lines, depending on the specs, Dynamics CRM offers enough with its Windows Workflow Foundation based workflow engine. In the CRM integration context, the different BPM products out there are essentially about managing workflows with a third party software that does what CRM Workflows (WF) can do and more.

So why would one use a BPM tool when CRM already offers some workflow capabilities? Here are a few reasons that I think are key to help deciders make a sound decision on whether to invest in a BPM tool to integrate with CRM or not…

Workflow Complexity

When building very complex and long workflows, the Microsoft Dynamics CRM workflow editor is very limited and it can become very frustrating and reduce productivity:

  • The user interface is sometimes slow to respond (especially when there is a lot of custom code)
  • You can only go (I think) 5 or 6 levels deep and create child WF if you want to go deeper
  • It’s not easy to read at all

BPM tools often provide a better workflow design experience by using visual editors, either custom built or on top of other applications (e.g. MS Visio, MS Visual Studio etc.). That makes the workflows easier to build and to read. It also takes away the “levels” issue, removing the need to create child workflows when you have more than 5 deepness levels.

Workflow Systems Integration/Complex Workflow Operations

If you need your workflows to talk to other systems (web service calls, external connectors etc.) or just to perform some more complicated operations (retrieve multiple, bulk delete/update etc.), it’s all possible in CRM by creating custom workflow activities (.NET Code). These would have the logic within them to make the necessary web services/external calls/complex operations. Some BPM tools provide with the ability to integrate web services calls or make complex operations with simple configuration (no code). A few good reasons to use a BPM tools in this context would be:

  • You don’t have the Dynamics CRM expertise in house to build the custom pieces (custom workflow activities)
  • You have so many different external calls/integration to do within the workflow that it’ll create too much custom code resulting in more difficult debugging and costly maintenance in the future

Workflow Version Management

Depending on what the WF does, you may need to keep a detailed history of WF execution, including which version of WFs have been triggered for specific records. Also what CRM is lacking is a workflow “live update” feature. Say you trigger a WF on record A and it gets to some wait mode. At which point you update the WF in the CRM solution. Well, the version of the WF that is executing against record A is still the “old version” of the WF and you cannot change that. Some BPM tools have this feature built in.

Workflow Looping Mechanism

CRM Workflows don’t really allow looping. You can create a mechanism where a WF keeps calling itself as a child but that has a very negative impact on performance and eventually, CRM kills the loop thinking it’s an infinite loop (managing resource consumption). BPM tools have the capability to use loops sometimes very easily and with a much lover impact on system performance. Something to think about if you have plenty of WF in waiting and looping mode in your system at the same time.

These are a few elements that can help you decide if you want and/or need to use a BPM tool with your CRM. From my experience, depending on what you are building, BPM add-ons can be costly so before going down that road, it is important to assess the need and selected the right solution based on these needs. On the flip side, if what you really need is  a BPM tool to manage your workflow/processes, do you really need CRM? Food for thoughts… There are plenty of options out there, including AgileXRM, K2, PNMSoft and many more. They all come with different features so just checking them out is an interesting exercise!

Cheers!