Category Archives: Customizations

USD: Remove individual hosted control parameters from memory

In our Unified Service Desk implementation (by the way, we’re live and everyone’s happy–YAY!), we are using a particular technique for showing the same entity type on multiple tabs. The nitty-gritty on how to do that is in this article I wrote a while ago.

The TL;DR on this is that we create more than one hosted control for a particular entity. When the entity record is requested, there’s a set of navigation rules that start looking at the URL parameter of the hosted controls, one by one. So if the first hosted control URL is empty, it loads that one, opening a new tab. Let’s say you call another record of the same entity type. It goes again through the navigation rules, checks the URL of the first hosted control, finds that it’s not blank or null, and then the next rule is fired, checking the URL for the second hosted control. If it finds it empty, then it loads that control in a new tab.

So much for a brief description.

When you close a tab, the hosted control parameters are kept in memory. One of the issues we found is that once you used a hosted control, if you close it, the control cannot be reused because the code looks for an empty or non-existing URL parameter to load up the different hosted controls. This would cause us to sometimes hit our control limit for that particular entity.

So we needed to clear the URL parameter. How?

The solution implemented is based on our USD custom panel, so it’s not handled via configuration. However, let me add before explaining that there’s a way to clear all parameters from a hosted control. You can do this by using the ClearDataParameter action, passing the parameter “name=topLevelTreeName“, where topLevelTreeName would be the hosted control or entity you want to clear. As it implies, it’ll clear all parameters for that entity; something you might want to do.

In our case, however, we only wanted to clear the URL parameter, and this is how we did it:

First, we set an event handler for the RequestApplicationClose event on the AppHost object:

 protected override void SessionCreatedEvent(Session session)
 {
     session.AppHost.RequestApplicationClose += AppHost_RequestApplicationClose;
     base.SessionCreatedEvent(session);
 }

This event handler is wired up when a new session is created by overriding the SessionCreatedEvent method, since you have an AppHost object for every session. Now we need to access the current parameters from the customer record. We do this with the following method:

private Dictionary<string, CRMApplicationData> GetApplicationParameters(string applicationName = "")
{
    var customerRecord =
        (DynamicsCustomerRecord)
            ((AgentDesktopSession) localSessionManager.ActiveSession).Customer.DesktopCustomer;
    if (customerRecord == null) return null;
    if (applicationName != "")
        return customerRecord.CapturedReplacementVariables[applicationName];
    var completeParameterList = new Dictionary<string, CRMApplicationData>();
    foreach (var appName in customerRecord.CapturedReplacementVariables.Keys)
    {
        var appParameterList = customerRecord.CapturedReplacementVariables[appName];
        foreach (var entry in appParameterList)
            completeParameterList.Add(entry.Key, entry.Value);
    }
    return completeParameterList;
}

This method returns all the existing parameters for the current customer record. We kept it generic so that we can reuse it for any future mad ideas we might have. Now we code in the new event handler for RequestApplicationClose:

private void AppHost_RequestApplicationClose(IHostedApplication app)
{
    var applicationParameters = GetApplicationParameters(app.ApplicationName);
    if (applicationParameters.ContainsKey("url"))
        applicationParameters.Remove("url");

}

Now we just look for the parameter, and kill it with fire. That’s it! This executes pretty fast with no noticeable performance hits; remember that this is set to run when the tab is closed, so the user is not left waiting for a process to run. This is a very easy way to remove parameters with pinpoint precision.

Advertisements
Tagged , , , , , , , ,

CRM 2015: Get your field value without losing focus

In CRM 2015 (and most probably in 2013), an entity attribute is not updated with the typed-in value until you exit that particular field via pressing Tab or by clicking somewhere else.

We have a few entities where we don’t necessarily expect the user to exit a field that needs to be validated. Usually these are end-of-form fields, where there’s nowhere else to go in that form, if you get what I mean. If they type a value and save the entity, the value wouldn’t register and the user would get an error, even though they are seeing their typed characters right in front of them.

Pretty confusing.

Seeing this, I wrote a very simple, quick JavaScript function that’s accessible to all our entities, since it resides in what we call our “root” script library. This is unsupported code, but we know and accept the risks; I expect that you understand that before going ahead and implementing this. Here’s the code:

function GetValue (fieldName, getText) {
    var inputType = Xrm.Page.getControl(fieldName).getControlType();

    if (getText == null) getText = false;

    if (inputType == "lookup") {

        if (getText)
            return Xrm.Page.getAttribute(fieldName).getValue()[0].id;
        else
            return Xrm.Page.getAttribute(fieldName).getValue()[0].name;

    }

    if (inputType == "optionset") {

        if (getText)
            return Xrm.Page.getAttribute(fieldName).getText();
        else
            return Xrm.Page.getAttribute(fieldName).getValue();

    }

    if (inputType != "standard") return null;
    var id = fieldName + '_i';
    var inputElement = document.getElementById(id); 
   
    if (inputElement !== null)
        return inputElement.value;
    else
        return Xrm.Page.getAttribute(fieldName).getValue();

}

The first thing we do is check the type of field we’re working with. Using that, we have some code to send back values for lookups and option lists. The parameter getText allows you to get the name or text descriptions if it’s set to true for these type of fields.

We now evaluate if the field is standard type; if not, we return a null value.

Finally, this is the part where we do the switcheroo. We create an id for a DOM element. The reason for this is that when a CRM field gets focus, an HTML input element is created on the fly; this is where you actually type into. As soon as you focus out of the field, that input is gone. The name format for that element is attributeName + “_i”. 

We build that name and then try to get an element with that name in our DOM. We only do it once because your cursor can only be focused in one field at a time. Wrapping things up, we check if the HTML input element exists (meaning that a field has focus and hasn’t been exited by the user). If found, we return the value of this input, otherwise we return the actual attribute.

Pretty straightforward, and works like a charm for us.

Tagged , , , ,

Using Telerik’s Fiddler to work with Microsoft Dynamics CRM

5-19-2015 1-51-56 PMWhat? You don’t have Fiddler?

My friend, you’re missing out, big time. Okay, let me help. First go here to the Telerik website and download the latest version. It’s free. I’ll wait here until you install it.

Got it? Okay, then let’s talk about it.

You might be wondering what my fuss is all about. You might also be wondering if this is some sort of paid advert, but I can assure you, I’m not related to Telerik in other way than as a customer. Turns out that Fiddler is one of the best tools you’ll find for debugging your CRM customizations.

This is how it works: In simple terms, when it’s active Fiddler intercepts every single web traffic call that is made from or to your computer to any other server, be it in the Internet or inside your company network. Not only does it catch all this traffic, it also presents the traffic in great detail.

This won’t be a full Fiddler tutorial, but I will list some ways you can use Fiddler in your CRM debug work. Also, I won’t show screenshots because I work at a financial institution and there’s a very slight possibility that some information might be decoded from any URLs I show here.

Reload an entity form

You know that with CRM 2013 and 2015, if you press F5 while debugging a page, you’ll go back in your form history to wherever you started. This is pretty bad when you’re using something like the IE Developer Tools script debugger, because you need to navigate all the way into the entity form you’re debugging, and then set up your break points again.

What Fiddler allows you to catch is the actual URL of the form being worked on. You can get this URL by clicking on the appropriate entry on the web traffic list (you’ll know what I’m referring to when you see it), select Inspectors from the upper-right area (the request area), and then select Raw view. Now you can happily copy this address, paste it into the browser, and press F5 to your heart’s content.

Missing web resources

Your form is not working properly and you have no idea why. Maybe you have a web resource that references another JavaScript library and it’s not finding it? Or some images are not loading? What could it be? Well, just by looking at the traffic, we can see any calls that are marked in red. Those calls have failed, and now we can use the inspector view for the request to verify if we have the correct path, although you could also do this in the timeline itself.

Failed service calls

You create your pretty request for the Organization Service to bring in some data and you get nothing. Hmm. Well, looking at in in Fiddler you can find out if the call itself has the correct syntax, and if so, you can look at the response with the JSON formatter and figure out if you actually got something back. Also works in the same manner with your on WCF services. Pretty handy, huh?

Performance evaluation

You can select however many rows from the traffic list and then switch the the Timeline graph showing the time spent on each call. This helped us a lot when fine-tuning the performance of our CRM implementation.

System element addresses

You want to use a certain CRM graphic (like a “Loading” GIF), but don’t know where it is? With a bit of trial and error you can find out the exact location of that resource, and then use it in your own web resources.

Are you still thinking about it?

As you can see, Fiddler is an excellent weapon in the arsenal of the well-prepared CRM developer. It helps us deal with some of the quirks we find when debugging CRM customizations, and even can help us figure out how Microsoft has put together some of the parts in the forms.

It’s solid, it doesn’t bog performance, it’s free, and it’s from a reputable company. Can’t ask for much more! Do you have any other ideas or ways in which Fiddler can help? Let us know here!

Tagged , , , , , , ,

CRM 2015: Business Rules and JavaScript don’t mix, unless you really like acetaminophen

frustration-600x450_1-100521350-origYep, I said it. And this might be my first real random musing, so bear with me.

In our CRM 2015 implementation with the Unified Service Desk we decided that, for some of the simpler custom entities, we would change the validation from JavaScript to Business Rules. That way we would be able to have an easy way to establish client-side validations and rules, and avoid having to code those rules. We would also have elegant field-level error messages instead of things like pop-ups. Sounded like an ideal thing.

In our real world, unfortunately, didn’t work out that way. Or at least it hasn’t so far.

There’s a few corny things about Business Rules. First, they execute in the order you activate them. Excuse me, Microsoft, but that’s a bit of a bone-headed implementation. That means that developers would need to have a list of the correct order of activation just in case they needed to work with the rules. Why couldn’t they implement a relative sequence number is beyond my comprehension. Hey, they did it with USD window navigation rules!

Second, they need to be defined at the entity level to be executed on save. That means that now you have a process running all the time, every time, for every save you perform in that entity, regardless if you activate the validation only 5% of the time.

Third, as I mentioned above, if you throw JavaScript into the mix, with Ajax calls, XRM, etc… Let’s say it gets really busy. Especially since Business Rules are nowhere as easy to debug and trace as JavaScript validations.

So what’s my final take on all this?

If you have a mostly vanilla CRM implementation, Business Rules might be the thing for you. This carries even more weight if you have Business Analysts putting in validations in your organization. No need to code these is a huge advantage.

However, if you have a highly-modified organization, with lots of heavy XRM, jQuery, and even DOM manipulation, your best bet is to stay away from Business Rules. In our implementation with the Unified Service Desk, where we have custom code for managing tabs in Save & Close, getting the Business Rules to work reliably has been a hair-pulling experience. The time you’ll spend spinning your wheels trying to get things working together is akin to herding cats: you might be able to pull it off, but in the end wonder if it was worth all the effort.

What’s your take on this? I’m interested to read other CRM developers opinion on this.

Tagged , , , ,