Implementing Dynamics 365 Service Bus Listener using Azure Function

One of the built-in triggers for Azure Function App is Service Bus (ASB) queue trigger, which makes Azure Function a listener for ASB events.
While Azure Service Bus provides a robust decoupling mechanism, the receiving side has to poll for messages or implement a listener. 

This trigger makes Azure Functions an ideal implementation component for Inbound Asynchronous Integration with Microsoft Dynamics 365,
one that allows you to write custom code, but releases you from explicitly writing a listener.
An Inbound Asynchronous Integration pattern describes scenarios where a business event occurs in an external application and must be reflected into Dynamics 365.
Processing of the event in Dynamics 365 does not occur immediately and sometimes no response is required from Dynamics 365 side (one way).

In this post I’ll walkthrough the process of setting an Azure Function as an ASB one-way listener which posts incoming messages into Dynamics 365.
To demonstrate posting a message to ASB I’ll use Postman.

Business Scenario:

Whenever a new Account record is created in Contoso’s ERP application, reflect the new Account data into Dynamics 365 CE.

Prerequisites:

1. Azure subscription allowing you to register apps, provision Azure Service Bus and Azure Function App
2. Microsoft Dynamics 365 9.x instance with admin privileges, a trial will do

Walkthrough:

1. Setup Azure Service Bus queue and make a note of the connection string
   
2. Register an AAD App and application user to allow using Microsoft Dynamics 365 Web API. Note the Application Id  and secret
   
3. Setup Azure Function App with Service Bus queue trigger
    
   1. In Azure Portal, click ‘Create a resource’
      
      
   2. Select Function App
      
      
   3. Search for Function App (classic) and create a new one
      
      
      
   4. Set Function details and click ‘Create’
      
   5. Select the new Function and click Function app settings
      
   6. Select 1 as Runtime version
      
   7. Select the Functions and Click New function
      
   8. Select Azure Service Bus Queue trigger with C#
      
   9. Set triggers details. Under Service Bus connection click new and select details for the ASB queue you set on stage 1
      
      
      
   10. Once back in the Function code, replace existing code with the code found here.
       This code parse the incoming message, authenticates to Dynamics 365 and create a new Account record.
       Replace the ApplicationId, Secret and WebAPIURL to match the details you noted on step 2 and your organization Web API URL.
       Save the Function and make sure it compiles.
       
       
       
4. Test by posting a message with the required format to ASB queue.
   You can post messages to ASB using Postman and this useful collection
   
   Make sure Azure Function processes the message
   
   and that the record was created in Dynamics 365
   
   
   

Advertisement

Post message to Azure Service Bus via Custom Workflow Activity

While Dynamics 365 Plug-ins allow declarative integration with Azure Service Bus via ServiceEndPoints, integrating through Custom Workflow Activity requires some coding.

So why would you prefer a Custom Workflow Activity over a Plug-in?
Here are just a few good reasons:

1. Cost-efficiency: A Custom Workflow Activity component can be embedded in Custom Actions, A/Sync. Workflow, Dialog (while it’s still here), while Plug-in component can only be called and operate via the Plug-in execution context. When you put time into writing code, you want to allow as much re-use as possible.
2. Declarative: once registered, Custom Workflow Activity can be leveraged by non-developers in various Processes, while Plug-in is usually accessible only to developers.
3. Ubiquity: A Custom Action wrapping a Custom Workflow Activity can be accessed from other processes, client side code, server side code and consumers external to Dynamics 365
4. Flexibility: unlike the built in declarative integration, addressing Azure Service Bus via code allows you to add conditional logic and also reduce the message payload (see component code).

Convinced or not, the following walkthrough demonstrates using the Post Message To Azure Service Bus Custom Workflow Activity component to post message to ASB queue.
You can view the source code here and modify as required.

Prerequisites:

1. Azure subscription allowing you to provision Azure Service Bus
2. Microsoft Dynamics 365 9.x instance with admin privileges, a trial will do
3. Access to Plugin Registration Tool

Walkthrough:

1. Setup Azure Service Bus and make a note of the connection string
2. Use the Plugin Registration Tool to register a ServiceEndPoint and the noted connection string
3. Download, import and publish the unmanaged solution available here
4. Configure the solution contained Workflow by selecting the registered ServiceEndPoint, stating semi-column delimited properties list and an optional custom message. Activate the Workflow Rule.
   
   
   
5. Test by manually activating the Workflow on a Contact record.
   If all goes well, a new message will appear in ASB queue. You can view the queue dashboard in Azure Portal.
   
   
   If you want to view the actual message content, you can use Azure Service Bus Explorer
   
   

Few implementation notes:

1. While the IWorkflowContext allows accessing the target record properties via Pre/Post entity images, this technique is not documented and therefor considered unsupported.
   For this reason, the code explicitly retrieves and push the required attributes values into the SharedVariables collection.
   The propertiesSet input parameter allows sending in a list of required properties.
2. Clearing the IWorkflowContext data heavy collections before posting it to Azure Service Bus can reduce the the message payload weight by ~80%, which can simplify handling the message and improve performance.

Plug-in ServiceEndPoint Integration – Minimize IPluginExecutionContext payload

Integrating Microsoft Dynamics 365 with Azure Service Bus (ASB) can be easily implemented via the Plug-in Registration Tool without writing any code.
With this integration method, each time the target business event occurs, the complete operation IPluginExecutionContext payload is automatically sent to ASB, though often you need only a small portion of the data.

For some integration scenarios you need to apply conditional logic to decide if and which ASB queue to target. For these scenarios, you can write custom code which allows you to programmatically post message to ASB from Plug-in/Custom Workflow Activity components.
This method, also allows minimizing the IPluginExecutionContext payload which can simplify the logic required to parse it and generally improve performance. Unfortunately, I could not find a way to reduce the payload to just the required data, only minimize it.

The following screenshots (ASB Explorer) describes 2 similar messages (Contact creation event) posted to ASB before (4656 bytes) and after minimizing the IPluginExecutionContext payload (1842 bytes).
As you can see, the full payload weighs ~2.5 times the minimized payload.

To minimize the IPluginExecutionContext payload while maintaining the data you need, follow these simple steps in your code:

1. Extract the required data from IPluginExecutionContext and add it to the SharedVariables collection
   
2. Clear the data heavy IPluginExecutionContext collections
   • InputParameters
   • OutputParameters
   • PreEntityImages
   • PostEntityImages

The following sample code extracts the lastname attribute from the IPluginExecutionContext, clears the redundant collections and posts the minimized context to ASB:

        public void Execute(IServiceProvider serviceProvider)
        {
            // Retrieve the execution context.
            IPluginExecutionContext context = 
                (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

            IServiceEndpointNotificationService cloudService = 
                (IServiceEndpointNotificationService)serviceProvider.GetService(typeof(IServiceEndpointNotificationService));

            // Extract the tracing service.
            ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));

            //extract target record data from InputParameters collection
            Entity contact = (Entity)context.InputParameters["Target"];
            //extract required data 
            string fullName = contact["lastname"].ToString();

            //add required data to the SharedVariables collection
            context.SharedVariables.Add("lastname", fullName);

            //clear redundant data from context 
            context.PreEntityImages.Clear();
            context.PostEntityImages.Clear();           
            context.InputParameters.Clear();
            context.OutputParameters.Clear();
            
            try
            {
                tracingService.Trace("Posting the execution context.");

                string response = cloudService.Execute(new EntityReference("serviceendpoint", 
                    serviceEndpointId),
                    context);
                
                if (!String.IsNullOrEmpty(response))
                {
                    tracingService.Trace("Response = {0}", response);
                }

                tracingService.Trace("Done.");
            }
            catch (Exception e)
            {
                tracingService.Trace("Exception: {0}", e.ToString());
                throw;
            }
        }
    }

The Strange Case of The Liquid Template fetxhxml Tag

I have been asked by one of my customers to investigate a problem related to the Liquid Template fetxhxml tag.
If you aren’t familiar with this powerful Liquid tag yet, it allows retrieving Dynamics 365 data using a standard FetchXML query. You can even leverage this tag to retrieve data a-synchronously.

Trying to reproduce the problem, I added a simple FetchXML query within a fetchxml tag in one of the Portal pages via the actual Web Page record, knowing that the front side editor disrupts FetchXML queries syntax.

Testing the query results in the target Portal page, I noticed that the query condition was ignored – the query returned all Contact records.

Returning to the Web Page and refreshing it, I noticed that the FetchXML query mysteriously changed – the closing  slash for each attribute element was replaced with a full closing <attribute> tag.

It seems that before saving the Web Page form, the text editor diligently ‘corrects’ my query to comply to XML hierarchy format. This behavior was reproduced with Chrome/Edge browsers on both UII/old forms UI.
Strangely enough, the changed query syntax is considered valid by Dynamics 365, but any query condition is completely ignored.
I am guessing a recent features update changed the text editor behavior, as this behavior does not exist on earlier Dynamics 365 versions. 

After searching Microsoft Portal documentation for the fetchxml Liquid Template tag finding no results, I started considering the option that this is not a bug, but maybe some kind of feature phase out. Naaah.

So until Microsoft fixes this glitch, how can you use conditional FetchXML queries and fetchxml liquid tags? By using XrmTookBox Portal Code Editor Plug-in which allows Portal content editing (among other features) without disrupting FetchXML queries

Integrating Dynamics 365 with Azure Function using Managed Identity

I love Azure Functions. These days, I have to restrain the tendency to solve every problem with this Swiss army knife. 

When designing Azure Function integration with Dynamics 365, one of the immediate questions raised is where to store connection strings, credentials and other sensitive details. 
The immediate answer is ‘Not in your code’. So where?

One option is to store sensitive details in the Application Settings store which is ‘encrypted at rest and transmitted over an encrypted channel.’
While this option is  quite easy to use, it isn’t considered most secured.

Another option is using Managed Identity with Azure Key Vault service.
With this option, Azure Function App is assigned an AAD identity, which is then authorized to access specific Key Vault secrets.
This option is considered more secured as the Function App is specifically granted access to  specific sensitive data, while Application Settings stored data is generally exposed.

In this post, I’ll walkthrough the process of setting and using Managed Identity to Integrate Azure Function with Dynamics 365. In this case, Dynamics 365 access details will be stored in Azure Key Vault.

For the walkthrough, I’ll use the Lead Landing Page scenario, replacing Flow component with Azure Function. Although a bit verbose, the process is quite simple.

Implementation Notes

• Like most Azure services, Azure Key Vault usage costs money. With Azure Key Vault, any retrieval of secret is paid for. In order to reduce costs, some caching mechanism (which will not be discussed in this post) is in order.

Prerequisites

1. Have accessible Microsoft Dynamics 365 instance
2. Have access to Azure environment with sufficient privileges to create Azure Function and Key Vault store.

Walkthrough

1. Register App with AAD

   Register a new Web App/API in Azure AD with a Client Secret and copy Application Id key and secret to Notepad.

2. Add an App User to Dynamics 365

   Follow this article: Add a new Application User in Dynamics 365

3. Create a Function App

   

   Set Function App details and click ‘Create’

   

   Add a new Function

   

   Select the HTTP trigger option

   

   Click ‘Create’ to complete Function creation

   

   Leave the function code as is for now, we will alter it later on.

   

4. Assign Function App with a Managed Identity

   Go to the Function App Platform Features tab and click ‘Identity’

   

   Click the ‘On’ button to assign a System identity and click ‘Save’

   

   Click ‘Yes’ to enable system assigned managed indentity

   

   You can see the newly assigned identity object ID

   

5. Setup Azure Key Vault store

   Create a new Azure Key Vault store

   

   Click ‘Create’ at the bottom of the screen

   

   Click ‘Add new’ under the Access policies blade.
   In the Add access policy, check Get and List in the Key Management Operations group.
   Under the Principal blade, find and select your Function App. Click ‘Select’.
   This will grant our Function identity access to the Key Vault secrets.

   

   Next, select a Resource Group for the Key Vault store. Click ‘Create’ to complete Azure Key Vault store creation

   

6. Store secrets in Azure Key Vault

   Find the newly created Azure Key Vault store or access it from the dashboard if possible.

   

   Access the Secrets area

   

   Click Secrets and ‘Generate/import’ to generate a new secret

   

   Set secret Name (select a self explanatory name, since once created, you won’t be able to see the actual secret value in the area).
   Set the secret string in the Value field. Click ‘Create’.
   In this case, the secret I defined is Dynamics Web API URL, similar to https://<ORGNAME>.api.crm<DATACENTERCODE>.dynamics.com/api/data/v9.1/

   

   In the same manner, add additional secrets to hold the applicationId and secret keys you copied after registering an app in AAD (step 1 in this walkthrough).

   

   Click each of the newly created secrets and copy the Secret Identifier, which will be used in the code to access the secret value

   

7. Update Azure Function Code 

   Go back to the Function created on step 3 above.
   Click View Files, add a new project.json file and paste in the following definition. Click ‘Save’.

   {
       “frameworks”: {
           “net46”: {
               “dependencies”: {
                   “Microsoft.Azure.KeyVault”: “2.4.0-preview”,
                   “Microsoft.Azure.Services.AppAuthentication”: “1.1.0-preview”                
               }
           }
       }
   }

   

   Go back to the function code and replace the existing code with the code found here (placed in Github for convenience).

   This code, triggered by an HTTP request from the Lead landing page, performs the following tasks:
   – Receives and parse Lead data
   – Extract Dynamics access details from Azure Key Vault
   – Use access details to generate an access token
   – Create a new Dynamics Lead record using Web API
   – Returns operation result to the caller

   In the GetDyn365AccessDetails method, replace the URLs for the three keys

   dyn365WebAPIURL, dyn365AppIdKVURL, dyn365secretKVURL with the URLs copied on step 6.
   Click ‘Save’.

   Click ‘Get Function URL’ and paste somewhere, as it will be used next

   

8. Hookup Lead Landing Page to Azure Function

   Last, create a new HTML page, and copy the HTML found here (placed in Github for convenience).
   Find the AzureFunctionRequestURL variable and replace its value with the Azure Function URL copied in the previous step. Save.

   

9. Test

   To test the solution, run the Lead Landing HTML page. Submitting Lead data should results with a new Lead record in Dynamics 365.

   

   

   If the flow fails, add the address from which the HTML page is executed to the Azure Function CORS collection to authorize it.

   

   

Referencing Dynamics Assemblies with Azure Function Apps v.2

Just stumbled upon a new  Azure environment, where Azure Function Apps have been upgraded to version 2.
Right away, noticed that my Azure Function code referencing Dynamics assemblies does not compile, complaining about

The type or namespace name ‘Xrm’ does not exist in the namespace ‘Microsoft’ (are you missing an assembly reference?)

After digging around, I found out that the project.json is not longer valid with v.2.
Instead, the function.proj file must be created and reference Dynamics assemblies in the following manner:

<Project Sdk=”Microsoft.NET.Sdk”>

  <PropertyGroup>

    <TargetFramework>461</TargetFramework>

  </PropertyGroup>

  <ItemGroup>

    <PackageReference Include=”Microsoft.CrmSdk.CoreAssemblies” Version=”9.0.0.7″/>

    <PackageReference Include=”Microsoft.CrmSdk.XrmTooling.CoreAssembly” Version=”9.0.0.7″/>

  </ItemGroup>

</Project>

Microsoft Graph API – Assign DYN365 License to AAD User

The automated process of user provisioning becomes common in many projects. Often, the process includes components outside of Dynamics 365 such as  creating a user in Azure Active Directory, assigning plans and licenses and adding user to AAD groups. All of these can be automated using the Microsoft Graph API.

In this post, I’ll demonstrate assigning Microsoft Dynamics 365 license to an existing user with Postman. You can later convert Postman requests to JS or C# code or use in Flow and Logic Apps.

Prerequisites

1. Have Postman application installed
2. Have access to Office 365 and Azure environments

Walkthrough

1. Register a new Web App/API in Azure AD with a Client Secret and copy Application Id key, callback URL and secret to Notepad.
   Make sure your app is granted the ‘Read directory data’ privilege

   

2. Set a request to retrieve available SKUs

   In Postman, create a new GET request to the following address, after replacing <YOUR_DOMAIN_NAME> with your actual domain name (e.g. bikinibottom.onmicrosoft.com)

   https://graph.microsoft.com/v1.0/<YOUR_DOMAIN_NAME>.onmicrosoft.com/subscribedSkus

   

3. Get an Authorization Token

   Before actually accessing the Graph API, you’ll need an access token to authenticate your requests.
   Click the Authorization tab, and set type to OAuth2.0.
   Click the Get New Access Token and select the Authorization Code option for the Grant type attribute In the dialog opened.
   Fill in the Client ID, Client Secret and Callback URL details copied previously to Notepad.

   

   Click the ‘Request Token’ button to receive a dialog containing an Access Token. Scroll down and clock ‘Use Token’ button

   

4. Retrieve Subscriptions

   Click ‘Send’ to execute the request which will retrieve a list of commercial subscriptions that your organization has acquired.

   
   
   If you have Dynamics 365 licenses, the following node will be included in the response.
   Copy the skuId value which will be used in the next step.

   

5. Assign License to User

   Create an additional POST request to assign license to user with the following URL. Replace the target user principal name 
   (e.g. sandycheeks@bikinibottom.onmicrosoft.com)

   https://graph.microsoft.com/v1.0/users/<USER_PRINCIPAL_NAME>/assignLicense

   In the Authorization tab, set the same settings as the first request. As you already have a token, no need to get a new one.
   Add a header of  Content-Type = application/json

   

   Set the request body with the previously copied skuId

   

   Click ‘Send’ to send the request and assign Dynamics 365 license to the target user.
   A correct response looks like this

   

 

 

 

Custom Code Tracing & Exception Logging in Dynamics 365 v.9

As a Solution Architect I often review Microsoft Dynamics 365 custom server and client side code.
One of the most common rejects regards tracing and exception handling mechanisms, or their absence. Some code constructs may have empty Try/Catch blocks or none at all, other catch exceptions and just re-throw. As for tracing, code often contains debugging ‘aids’ such as alerts and debugger statements or no tracing notifications at all.

Why is this a reject?

• Unhandled raw exceptions float to UI, confusing and frustrating users while exposing internal implementation details to potential attackers
• System Administrator is unaware of custom code exceptions unless users decide to report an error message or a bug
• Tracing mechanism help diagnose faults and sometimes allow resolving without debugging or recompiling code

Microsoft Dynamics 365 contains a Plug-in Trace repository which contains trace and exception entries originating from Plug-in and Custom Workflow Activity components.
While this is a good built in solution, it has some drawbacks:

• It does not support common types of custom code such as client side JavaScript and external components consuming Microsoft Dynamics API directly
• There is no straight forward method to filter Plug-in Trace notification to search for specific text in trace/exception messages
• No option to trigger a notification to system administrator once an exception is logged
• No option to accurately correlate a user reported error message to a specific exception entry

In this post I would like to suggest an updated implementation of a more wholesome infrastructure for tracing and exceptions logging. Using this  infrastructure, any developer can easily log trace entries and exceptions from any custom code interacting with Microsoft Dynamics 365 application, while admins can easily monitor the application health in that aspect.

WIIFM

Why using this infrastructure?

• Easily log trace entries and exceptions from any client and server side custom code interacting with Microsoft Dynamics 365 application in a unified manner
• You can add processes triggered by exception Log record creation to alert system administrator regarding a fault as it occurs
• Easily search and filter specific exceptions/trace records according to unique Reference Token provided by users/clients using Quick/Advanced Find

In the following How To Use section you can download a un/managed solution and follow setup and usage instructions.  You can view the GitHub project here.

How to use

1. Download and import solution

   You can download a managed solution here.
   If you want to make any changes to this solution, download the un-managed version. In that case, open the solution, navigate to the Log entity and check ‘Settings’ to display the entity in the settings area. Finally, publish the solution.

   

2. Using in an entity form JavaScript code
   
   Add the dyn_utils.js Web Resource to the target entity form libraries collection.
   Call the LogTrace and LogException functions in your custom code.

   

       //perform some business logic including tracing and exception handling 
       ns.DoSomeBusinessLogic = function () {
           //define verbose trace entry
           var traceEntry = {
               //title
               "title": "loggingSample.DoSomeBusinessLogic",
               //description
               "description": "Start execution",
               //related business record id 
               "relatedBusinessRecordId": "2514FC63-9E58-4D1E-8226-69256D0197E3",
               //related business record URL
               "relatedBusinessRecordURL": "https://xxx.crm.dynamics.com/main.aspx?etc=8&extraqs=&histKey=520872127&id=%7b2514FC63-9E58-4D1E-8226-69256D0197E3%7d&newWindow=true&pagetype=entityrecord#923042",
               //set current user id as related user id 
               "relatedUserId": getContext().userSettings.userId
           };
   
           //trace function execution start asynchronously
           Utils.LogTrace(traceEntry, true, SuccessHandler, FailureHandler);
   
           try {
               //some business logic including some exception 
               NonExistingFunctionCall();
           }
           catch (err) {
               //define verbose exception entry
               var exceptionEntry = {
                   //title
                   "title": "loggingSample.DoSomeBusinessLogic",
                   //description
                   "description": Constants.MSG_GENERAL_FAILURE,
                   //related business record id 
                   "errorMessage": err.message,
                   //related business record URL
                   "stackTrace": err.stack
               };
   
               //log exception and return reference token
               var referenceToken = Utils.LogException(exceptionEntry, false);
   
               //notify user with a reference token to report back to admin
               alert(Constants.MSG_GENERAL_FAILURE + referenceToken);
           }
           finally {
               //define thin trace entry 
               var traceEntry = {
                   //title
                   "title": "loggingSample.DoSomeBusinessLogic",
                   //description
                   "description": "Start execution",
               };
   
               //trace function exectuion end asynchronously
               Utils.LogTrace(traceEntry, true, SuccessHandler, FailureHandler);    
           }
       }
   

3. Using in Web Resource JavaScript code

   You can view the code in action by launching the dyn_loggingSample.htm Web Resource (replace organization base address)
   https://YOUR_ORG_NAME.crm.dynamics.com//WebResources/dyn_loggingSample.htm
   
   

   Make sure you include the dyn_utils.js as a referenced resource:

   
   
       
       Logging Sample
       
       
       
       
   
   

   The sample code in the dyn_loggingSample.js demonstrates tracing and exception handling, same as in the code sample above.

4. Using in Plug-in/Custom Workflow Activity/external SDK client

   The following code sample represents usage in Plug-in and is similar to CWA and external SDK client usage:

       public class LogTraceAndException : IPlugin
       {
           public void Execute(IServiceProvider serviceProvider)
           {
               // Obtain the execution context from the service provider
               IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
               // Get a reference to the organization service
               IOrganizationServiceFactory factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
               IOrganizationService organizationService = factory.CreateOrganizationService(context.UserId);
   
               //define a trace entry, all attributes are optional except title 
               Log traceEntry1 = new Log
               {
                   title = "ServerSideLogging: Execute",
                   description = "Execution end",
                   //replace user id with an valid one
                   relatedUser = new EntityReference("systemuser", 
                       Guid.Parse("37ACCC73-0FCE-474B-A206-19C08163438B")),
                   relatedBusinessRecordURL = "https://YOURORGNAME.crm.dynamics.com/main.aspx?etc=1&extraqs=&histKey=87055256&id=%7b381FA757-60D7-E811-A97E-000D3AB20035%7d",
               };
   
               //log trace entry, get reference token back 
               string refToken1 = GenericLogging.Log(traceEntry1, 
                   GenericLogging.LogType.Trace, organizationService);
   
               try
               {
                   //some exception raising code.
                   //If transaction is rolled back, Log entries will persist
                   throw new Exception("An error occurred, please notify the System Administrator");
               }
               catch (Exception ex)
               {
                   //define an exception entry 
                   Log excptionEntry = new Log
                   {
                       title = "ServerSideLogging: Execute",
                       errorMessage = ex.Message,
                       stackTrace = ex.StackTrace
                   };
   
                   //log exception entry, get reference token back
                   string refToken2 = GenericLogging.Log(excptionEntry,
                       GenericLogging.LogType.Exception,
                       organizationService);
   
                   throw new InvalidPluginExecutionException(
                       string.Format("An error occurred, please notify the System Administrator. Reference token: {0}", 
                       refToken2));
               }
           }
       }
   

   A resulting exception raised from the Plug-in code includes the reference token. Once reported to an Admin, he can easily find the relevant Log entry using Quick Find

   

   

   

Implementation Notes

I have written about the subject in the past and the described approach has not changed much. The implementation has been updated to leverage version 9 features (currently available on for Online implementations)

What has changed since last version:

• Using Action definition to activate, deactivate and control logging level
• Using built-in auto-numbering attribute to generate reference token, so a designated CWA component is no longer required
• Optional usage of client side asynchronous logging operation to keep UX uninterrupted

In order to support logging from transactional components (such as Plugin registered to pre/post operation stages), the Log method in GenericLogging.cs file is using the ExecuteMultipleRequest class to execute the dyn_Log request.
As the ExecuteMultipleRequest instance is external to the Plugin transaction, it manages to create a Log record without the Plugin transaction rolling it back.
Using the Execute method directly with the dyn_LogRequest request instead, would have executed the Log Action, but the created Exception record would have been deleted by the Plugin transaction rollback, leaving no trace.

 

Drag & Drop File Upload Revisited

Finally found the time for overdue maintenance on the Drag & Drop solution I created two years ago.

Why revisit?

First of all, as the CodePlex platform, previous home of this solution, is being decommissioned, downloading the component got the whole CodePlex project and few visitors commented that they could not find the actual solution.
So now you can download an unmanaged solution from it’s  new home @ Github.

Second, I fixed a major bug related to the plural name of some entities.
For most entities, appending ‘s’ to the entity schema name would result in the matching entity name for Web API. Some entities, like opportunity, do not match this pattern.

Third, I wanted to update the Web API version to 9.0 and to make sure the solution works with Dynamics 365 Online current version.

Microsoft Portal – Retrieve Dynamics 365 Data Asynchronously – Part 2

In part 1 of this post I demonstrated building and using a service which receives a FetchXML query and returns Dynamics 365 data to any Portal page in an asynchronous manner as a JSON object. This service is similar to the SDK’s RetrieveMultiple message.
In this part 2, I’ll demonstrate a different service, which like the SDK Retrieve message, receives a record type, record id (GUID) and columns set to return the required data as a JSON object.
This is useful when you already have a specific Dynamics 365 record id at hand and you want to retrieve additional data for this record.

1. Create a Web Template  named RetrieveService

   Set the Mime Type is to application/json.
   

   Paste the following code in to the web template source and save.

   {% comment %} test for required parameters {% endcomment %}
   {% if request.params[‘entityname’] and request.params[‘id’] and request.params[‘columnset’] %}

   {% capture msg_no_data %}No data for specified attribute {% endcapture %}

   {% comment %} extract parameters {% endcomment %}
   {% comment %} extract target entity {% endcomment %}
   {% assign entityname = request.params[‘entityname’] %}
   {% comment %} extract target record id {% endcomment %}
   {% assign id = request.params[‘id’] %}
   {% comment %} parse requested attributes into array {% endcomment %}
   {% assign columnset = request.params[‘columnset’] | split: “,” %}

   {% comment %} query for target entity  {% endcomment %}
   {% assign item = entities[request.params[‘entityname’]][request.params[‘id’]] %} 

   {% comment %} Emit JSON response {% endcomment %}
       {% if item %}{
           {% comment %} Iterate throguh requestd attributes array {% endcomment %}
           {% for att in columnset %}
               {% comment %} Handle optionset attribute {% endcomment %}
               {% if item[att].label %}”{{ att }}”:”{{ item[att].label | default: msg_no_data }}”
               {% comment %} Handle lookup attribute {% endcomment %}
               {% elseif item[att].name %}”{{ att }}”:{“name”:”{{ item[att].name | default: msg_no_data }}”,”id”:”{{ item[att].id | default: msg_no_data }}”}                           
               {% comment %} Handle other attributes {% endcomment %}
               {% else %}”{{ att }}”:”{{ item[att] | default: msg_no_data }}”
               {% endif %}{% unless forloop.last %},{% endunless %}
           {% endfor -%}                   
       }   
       {% endif %}

   {% comment %} handle missing parameters {% endcomment %}
   {% else %}
     { “error”:”Missing one or more required parameter(s): entityname, id, columnset” }
   {% endif %}

2. Create a Page Template named RetrieveService
   Map the Page Template to the Web Template created on step 1 above.
   Uncheck the Header and Footer checkbox.
   
   

3. Create a Portal Page named RetrieveService
   Set Home as parent page.
   Map the page to the Page Template created on step 2 and copy the partial URL which is used in the next step

   

4. Consume Service

   Use the following code sample anywhere you need asynchronous data retrieval of from Dynamics 365. In my example it is located in the Home page JavaScript portion.
   Note the URL address which maps to the Page (created above) URL.
   Replace the entityname, id and columnset parameters.
   Most important: make sure your users have the required Entity Permissions for the entities queried, otherwise they will receive empty results.

   $(function (){
     //define asynchronous request from any portal page
       $.ajax({
           method: “POST”,       
           url: “/retrieveservice/”,
           data: {
               //define entity name, id and columnset 
             entityname: ‘incident‘,
             id: ‘D2A697CD-D3C7-E811-A965-000D3AB0F1D7‘,
             columnset: ‘ticketnumber,title,createdon,incidentid,statecode,caseorigincode,customerid,ownerid‘  
           }
       }).done(function (msg){
           console.log(msg);
       }).fail(function (jqXHR, textStatus, errorThrown){
           console.log(textStatus);
       });
   });

   As the sample code logs the resulting JSON object to the console, open the browser developers tool (F12) to view it.