Yet we do need such workflows – the most obvious example of why we do is “age” calculations. After all, people do want to send out an email to the customers/contacts having a birthday today.

However, at some point, I actually gave up on the idea to use recurring workflows since I could never make them work.

There are workarounds, of cause. One can write a console application/windows service/etc to do something in CRM periodically. Well, it works for some of us, and it does not work for others. After all, you have to deploy and schedule that application somewhere, and that introduces other issues.

I’ve been dwelling on it for almost half a year, and, it seems, I’ve finally got my “a-ha” moment just a few days ago. There are recurring jobs in CRM, and those jobs are perfectly “legal” from CRM standpoint. One can always create a bulk delete job and schedule that job to run daily. Well, no, not more frequently. You’ll have to schedule more than one job for that.

However, the point is, a recurring workflow can, then, be implemented like this:

• Create a new entity
• Schedule bulk delete job that deletes all records of that entity type
• Add a workflow for that entity which starts whenever a record is deleted
• Do whatever you need in that workflow (if you need a custom workflow activity, or a plugin.. go ahead)
• At the end of the workflow, create new record of the same entity type

Here you go – you’ve got a recurring workflow, and CRM has nothing to complain about.

Chrome:

IE:

PS. Apparently, the very first javascript customization I checked did not work:) Well, there is work to do.

I figured that I may need to see which field is causing this, so, here is a javascript code snippet which does this job – if you run into a similar situation, just add a web resource with this code, and, then, add a call to showDirtyAttributes to the “onSave” event of your form:

function showDirtyAttributes()
{
   var names = “”;
   Xrm.Page.data.entity.attributes.forEach(function(attribute, index)
     {
       if(attribute.getIsDirty())
       {
          names += attribute.getName()+”;”;
       }
     });
    alert(names);
}

It actually helped – to some extent. It turned out one of the lookup fields did not like the reference assigned to it for some reason. It did work, I could navigate from that field to the referenced record.. However, I had to update that referenced record and choose it for the lookup once again to finally get rid of the “do you want to save the updates?” dialog.  I’m still wondering what was so unique about that record, though..

Here is the scenario: there is a client-side java script, and we need to:

- Initiate some server-side processing

- Get the results of that processing back to our javascript

A potential solution to that might be to implement a web service which would encapsulate server-side logic, and to call that web service from our javascript. That might not work with Dynamics CRM online since we can’t deploy our web service on the CRM server, and, so, we may end up with a cross-domain call from our javascript. That’s not to mention that we’ll need to deploy our web service somewhere.

As of now, the only type of server-side processing we can use in Dynamics CRM online is called “plugins”, though. So, can we use CRM plugins in the scenario described above?

Surprisingly, the answer is yes.

First of all, there is a straightforward solution. We might register a plugin which would kick in whenever a new record of specific type is created. We might create a record of that type using javascript; we might pass some parameters to the plugin through the record fields; and, then, we might get the results back through another record (which would be created by the plugin). Would it work? I guess it would. However, we’ll have to work around possible concurrent calls, and, in general, I don’t like the idea of having to store intermediate results in CRM database.

There is another solution which still requires a dedicated entity type, but no CRM records of that type will ever have to be created. Here is how it works:

• We need an entity to pass data from our plugin to javascript
• We need to register a post-operation plugin on “RetrieveMultiple” for that entity
• We also need to register a pre-operation plugin on “RetrieveMultiple” for that entity
• Finally, we need to have a javascript that will make retrievemultiple request to CRM using fetchxml. That fetchxml will basically ask CRM to return all records of our entity type, and it will also pass whatever parameters we need to pass to the plugin through fetchxml conditions

The point is: such a request from the javascript will activate both of the plugins (pre/post operation). In the pre-operation plugin, we will extract request parameters from fetch xml conditions. In the post-operation plugin, we will populate context.OutputParameters[“BusinessEntityCollection”] with the fictitious records. As a result, our javascript will receive those records, and that’s how it will get data from the plugin. That’s when we’ll have our mission accomplished – we will have a javascript which uses CRM plugins to do server-side processing, yet we will not have to store any data in CRM.

The reason we need two plugins in this scenario is that we don’t have access to the fetch xml in our post-operation plugin, although we still need a post-operation plugin to create results for the javascript.

Basically, all we have to do in the pre-operation plugin is to extract request parameters from the fetch xml and pass those parameters to the post-operation plugin through the SharedVariables collection of plugin context.

In the post-operation plugin, we can do whatever server-side processing we need to do (based on the request parameters that we’ve already extraced in the pre-operation), and, once it’s done, we can populate [“BusinessEntityCollection”] member of the context output parameters collection (in case with this property, we can’t do it in pre-operation.. so, again, we need both pre and post-operation plug-ins in this scenario).

Just to add a bit more clarity, here is a quick diagram:

Finally, here is a real-life scenario where I used this approach:

• My client wanted to implement javascript-based “behind the scenes” address verification with QAS (qas.com)
• QAS web service is hosted on QAS server, so any attempt to use javascript to call that service ends up with a cross-domain call
• On the other hand, it’s not a problem at all to implement that sort of verification in C#

This fits the scenario described above quite nicely. I have a javascript that makes retrieve mutliple request using fetch xml. There are two plugins on the CRM side. Pre-operation plugin extracts address details from fetch xml. Post-operation plugin makes a call to QAS web service, and, depending on the results of that call, creates a fictitious record  (that record never gets stored in CRM), adds that record to the BusinessEntityCollection, and that’s how my javascript receives the results back.

“What did CWR Mobility and Microsoft announce?

CWR Mobility and Microsoft announced on February 6, 2012 that the Microsoft Dynamics® CRM Q2 2012 service update will deliver the capability for customers to access the complete functionality of Microsoft Dynamics CRM on any device with a new cloud-based, cross-platform, native mobile client service called Microsoft Dynamics CRM Mobile for Windows® Phone 7, iPad®, iPhone®, Android™ and BlackBerry®  mobile devices.”

See details here: http://www.cwrmobility.com/mobile-crm-faq

That did not happen in summer, though. However, Microsoft has recently published it’s December release preview guide which sticks to the point that Dynamics is really going to be supported on tablets and browsers-other-than-IE, so it may still happen.. or may not:

http://crmpublish.blob.core.windows.net/docs/Release_Preview_Guide_December_2012_FINAL.pdf 

That, combined with the fact that I’ve spent a couple of days this week evaluating Resco.NET and CWR for the client, multiplied by the fact that most of the users would love to customize Dynamics UI a little(or far) beyond what’s available out of the box, kicked of a different thought process. It would be great if someone came up with a powerful UI framework for CRM applications. Such systems as Dynamics and Salesforce have very efficient backends. However, when it comes to the UI, you suddenly feel like your very basic freedoms have been cut off. After all, I do want to be able to see a different logo when I log in. I do want to play with filters, forms, views – that’s what most of the users will be working with. But I can’t.

And I don’t think I’m alone here, though some people may be taking it to the extreme (or are they?):

http://social.microsoft.com/Forums/en/crmdevelopment/thread/56355a6e-0333-4b0a-a0ba-6a05709a6436

What CWR example really demonstrates, though, is that it’s doable, and Resco.NET gives yet another example (On a side note, I’m not sure if I like CWR more).

So, would it be possible? Do you happen to know of any existing UI frameworks that can be easily connected with Dynamics? Should we kick off a codeplex project to finally give different faces to Dynamics CRM?

PS. With that said, December release preview does mention browsers support, and it does not mention native clients. What’s interesting is that it specifically mentions very recent browser versions for non IE browsers(Chrome v22, for instance), which might be a hint of HTML 5 client being developed for Dynamics. December release preview also does not mention support for Android tablets, and CWR does have that support.. So, after all, maybe the deal did not work out and we are going to see something completely new from Microsoft.

Unfortunately, even though it seems reasonable, this feature is not supported out of the box. Moreover, Dynamics CRM uses SSRS for reporting, and, to the best of my knowledge, SSRS does not support this feature either. This is not to mention that we have limited control over SSRS functionality when working with Dynamics CRM in general and with the online version of Dynamics CRM in particular.

We can make it work, though, and you will find step-by-step instructions below. Please keep in mind that this solution uses some of the undocumented java script SSRS-related objects which may or may not exist in the newer versions of Dynamics CRM. As of now it works, though, and, I believe, all those undocumented features (there are really just one or two) will be available in the future.

So, here is what we have out of the box:

It is the last step that we want to eliminate:

We want to be able to name the file automatically as part of the “Export to PDF” step.

Here is how we are going to do it:

1. We will do it using “salesorder” entity as an example, but it is easy to do the same for other entities as well.
2. We will create a java script that will be loaded as a web resource to the order form.
3. In that java script, we will define a single function that will be called in form “onload”.
4. That function will re-define window.open so that we can run additional code whenever user decides to build a report.
5. Our additional code will use java script setTimeout in order to wait until the report is loaded, and, then, modify report file name.

We will be using undocumented features of Dynamics CRM only once: in order to modify the file name, we will have to access java script instance of the reporting component. I believe this part of Dynamics CRM functionality is not really documented, but one can always use Internet Explorer developer tools (F12) to do some research.

Let’s take a look at the details:

• Create a new web resource (jscript)
• Give it a name (let’s use “new_reporting”)
• Using web resource “text editor” button, add the following java script:

function setHandlers()
{
  var newFileName = Xrm.Page.getAttribute(“ordernumber”).getValue();//Change attribute name for other entities
  window.open = function (open) {
     return function (url, name, features) {
        var timeout = 2000;
        var newWindow = null;
        if(features != null) newWindow  = open(url, name, features);
        else if(name != null) newWindow  = open(url, name);
        else newWindow  = open(url);
        function timeoutFunc()
        {
                 var rv = null;
                 var r = null;
                 try
                 {
                    rv = newWindow.frames[ "resultFrame" ].$find(“reportViewer”);
                    r =rv._getInternalViewer();
                 }
                 catch(err)
                 {
                    setTimeout(timeoutFunc, timeout);
                    return;
                 }
                 if(r == null)
                 {
                    setTimeout(timeoutFunc, timeout);
                    return;
                 }
                else
                {
                      var url = r.ExportUrlBase;
                      var i = url.indexOf(“FileName=”);
                      var j = url.indexOf(“&”, i+1);
                      var oldFileName = url.substring(i+9, j);
                      r.ExportUrlBase = url.substring(0,i) + “FileName=”+ newFileName + oldFileName + url.substring(j);//Use this line to assign new file name
                }
        };
        if(url.indexOf(“viewer.aspx”) > 0)
        {
           setTimeout(timeoutFunc, timeout);
        }
        return newWindow;
     };
  }(window.open);
}

This function does the following:

• It overrides window.open with a new function
• Whenever another java script makes a call to window.open, our overridden version will be called instead
• First, we will forward that request to the original window.open. After that, we will verify if requested url contains “viewer.aspx” substring. If it does not contain such a substring, we don’t need to do anything.
• If it does contain the substring, we will use setTimeout using internal “timeoutFunc” as a parameter
• The purpose of the internal “timeoutFunc” function is simple:
• It will verify if the report is loaded. If not, it will call another setTimeout, and it will keep doing it until the report is finally loaded (yes, there could be potential problem here)
• If the report has been loaded, finally, it will update “ExportUrlBase “ property of the reporting control

And that’s, pretty much, it.

What’s left is:

• Save this web resource and publish it
• Add this web resource to the order form
• Add “onload” event and specify setHandlers java script function for that event
• Save order form and publish it

Finally, verify the results:

Hope this helps.

SSIS adapter is convenient, it does the job, and, now, it’s the first tool that comes to mind.

Why?

Because it is different now.. There are SSIS adapters for Dynamics CRM from such companies as kingswaysoft.com, CozyRoc.com, and, probably, from some others. Those adapters make it much easier to create SSIS packages for Dynamics CRM.

I tried to look up a comparison of Scribe and SSIS (for Dynamics CRM), and the following link came up:

http://cowia.com/ssis-vs-scribe/

Let’s face it – it’s not the best link. But it pretty much reflects my own subconscious ideas I had until recently, so I’ll still use it. The thing is, however, I believe that post is quite outdated now. Here is how it should look:

• Scribe has CRM adapter. SSIS has CRM adapters
• SSIS is free tool from Microsoft. Scribe needs a license(and an expensive one)
• SSIS has super performance. And you don’t need to spend a lot of time coding (because there is an adapter now)
• Scribe has great performance – much less time needed to get your solution ready. This one is quite controversial. It really did not take that much time to create an SSIS package.

And there is one item that I would still give to Scribe: automation, notifications, easy to install and redeploy. I’m not sure that justifies the cost of licenses, though. Since Scribe licensing depends on the number of CRM users, and none of the SSIS adapters I’ve seen so far take number of users into account, the difference can be more than significant (2k vs 20K).

There are a couple of workarounds:

• Use another machine to login to another instance of CRM online
• Use “run as” to start IE under another user account

Maintaining a physical or virtual machine just for this seems to be a bit of an overkill. However, having to enter windows credentials in the windows “run as” dialog every time I need to start IE under another user account becomes quite annoying over time.

There turned out to be a simple solution..

• You will need a new user account (it might be local or domain account)
• You will need to create a batch file and put the following in that file:

      runas.exe /savecred /user:”DOMAIN_OR_COMPUTER_NAME\USERNAME“  “C:\Program Files\Internet Explorer\iexplore.exe”

The first time you run that batch file, it will ask you for the user password. Once IE starts, login to CRM (don’t forget to enable “remember me” checkbox). That will be one-time setup. After that, you won’t have to enter usernames/passwords anymore – just start the batch file and navigate to CRM location.

Well, I had quite a few thoughts myself, so I had to make sure I don’t articulate what I think. Instead, I brought up the most powerful troubleshooting tool I know of.. which is called “Google”, of cause.. and it did not take me long to figure out that here is what I needed:

<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<system.net>
                <defaultProxy useDefaultCredentials=”true”>
                    <proxy usesystemdefault=”true”/>  
                </defaultProxy>
                </system.net>
</configuration>

There was a corporate proxy in this environment. For whatever reason, neither BIDS nor Dynamics CRM could make it through the proxy to the online Dynamics CRM instance. I am not sure if any of those applications are implemented in .NET from top to bottom, but, at least, Dynamics CRM portion must be using .NET since adding defaultProxy section to the configuration files did help in both cases.

For BIDS, “defaultProxy” should be added to the devenv.exe.config.

For Scribe, I actually went on and added this section to each of the configuration files (you will find those files in the Scribe folder).

So, this post describes a javascript solution that allows for a few things:

• Create a drop down where we would normally have to use a lookup
• Propagate selected reference and/or text to the pre-existing entity field
• Implement parent-child relationships between two or more dropdowns

This solution does use a bit of HTML manipulation to replace image web resource with a drop down, but, other than that, it relies on OData services and Xrm.Page client-side API.

You will need to download a couple of Dynamics solutions:

http://gotchahunter.net/downloads/GotchaHunter_1_0.zip

http://gotchahunter.net/downloads/GotchaHunterTests_1_0.zip

Please note that both solutions are unmanaged. The first one contains web resources only, so it is safe to deploy it.

The second one is for testing only since it has some customizations, yet it adds some other entities (such as country and province). In other words, use it as a reference and feel free to play with it in the test environment. Make sure you know what is there before you install it into a more “permanent” environment.

For the purpose of this blog post, you can use the second solution only (since it also contains all the scripts).

So, follow these steps to try the solution:

1. Get a clean instance of Dynamic (CRM online would do )
2. Deploy GotchaHunterTests_1_0.zip and publich customizations
3. Make sure tcs_country and tcs_province entities are visible in the workplace (if not, update those two entities)
4. Create a couple of countries
5. Create a few provinces for at least one of those countries

   

6. Now, go to one of the contacts
7. Notice that you have two dropdowns. When you change selected item for any of those dropdowns, original text fields will be updates, too:



8. Technically, you don’t need to display those original text fields on the form, so you could update the form to “not display” those fields by default(just do not remove them from the form)

And that’s, pretty much, it. In the next post, I’m going to explain how to make these dropdowns work from scratch, without using my “Tests” solution (that’s where you will need the first link above – that solution contains all the required scripts and no other customizations).