In part one of this series, I explained the basic idea behind a macros system for Dynamics CRM and a situation in which you'd want to use it instead of a workflow for process automation. I explained the structure of the macros system and showed the CRM entity form customizations that are required to implement it in part two. In this final part I'll show the ASP.Net code that does the heavy lifting for our basic policy renewal example.
The macros page
As I mentioned earlier, we use an ASP.Net Web Forms application to run the macros system, so we need to create a .aspx page for the policy macros. Because we believe in separation of business logic and presentation, our .aspx page requires two separate files, the .aspx page itself and its code-behind.Our .aspx page has two sections. First, there is the list of links that trigger the various macros. It looks something like this:
<asp:LinkButton ID="renewLinkButton" CssClass="text" runat="server" OnCommand="RenewPolicy" CommandArgument="Renew"> Renew policy </asp:LinkButton> <br /> <asp:LinkButton ID="anotherLinkButton" CssClass="text" runat="server" OnCommand="SomethingElse" CommandArgument="Renew"> Another macro </asp:LinkButton>
We make extensive use of macros, which means we've got a lot more links, so we group them into different sections based on the category of business process we're automating. Our macros pages are also styled to look similar to the rest of the CRM interface in terms of colors and fonts, so the end users have no idea that macros are not part of the main application.
The second section is an ASP.Net literal control we use to display a message back to the end user as required. It looks like this:
Our macros system doesn't actually do any actual CRM data processing in the code-behind layer. We keep all of that in a separate library (or try to, anyway) for ease of maintenance and testing. This next bit of code presumes you will be encapsulating your own CRM functionality in a similar fashion, but you could just as easily write the CRM code inline. (Disclaimer: this isn't the actual code we use. I've simplified it somewhat for illustrative purposes.)In case you've forgotten from part one, we want the code-behind method to:
- Update the current policy record to show that it was renewed.
- Create a new policy record that is a clone of the previous one with its renewal date pushed ahead one year and some blank fields for the user to supply new commission and premium data.
- Take the user from the old policy form to the new policy form.
As you can see, the code here is extraordinarily simple. Once you have the macros structure in place, you can add all sorts of enhanced functionality to your Dynamics CRM deployment.