Implementing No Code Dynamics 365 Service Bus Listener using Logic Apps

My last post demonstrated how to implement Dynamics 365 Service Bus listener using Azure Function.
This implementation type requires writing code and if you need absolute flexibility, Azure Function is a great solution. Additionally, Azure Function Apps support pay-as-you-go pricing with free grants, which should be considered when planing your architecture costs.

So why would you want to replace Azure Function with Logic Apps?
Mainly because in many cases, no code is required to implement patterns like Inbound Asynchronous Integration. This enable non-developers to implement complex integration scenarios in very short time.
How is this achieved? By leveraging Logic Apps built-in connectors to ASB, Dynamics 365 and numerous other applications. You can even expose custom connectors to your organizational APIs.
When working with Logic Apps, you should note that triggers (except HTTP WebHook trigger) use polling to detect relevant business events. While you can manage the trigger polling interval, you are billed by each polling action (trigger invocation) even if there is no relevant business event to operate on.

Using the built-in Dynamics 365 connectors allow simple CRUD operations but using the Command pattern can enable more advanced approach, where Logic Apps creates a Command (custom entity) record and Dynamics 365 A\Sync. Workflow operates on the request.

In this post I’ll walkthrough the process of setting a Logic Apps process 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 provision Azure Service Bus and Azure Logic Apps
  2. Microsoft Dynamics 365 9.x instance with admin privileges, a trial will do

Walkthrough:

  1. Setup Azure Service Bus queue 
  2. Setup Logic App process as ASB listener
    In Azure portal click ‘Create a resource’, type ‘Logic App’ and then ‘Create’
    undefined
    undefined
    undefined
    Type in Logic App details and click ‘Create’.
    Once created, navigate to the new resource
    undefined
    Select ‘When a message is received in a Service Bus queue’ trigger
    undefined
    Click +
    undefined
    Enter a meaningful connection name and click to select existing ASB queue. Then click ‘Create’ and ‘Continue’
    undefined
    undefined
    Change the polling interval if you want and click ‘+ New step’
    undefined
    Type ‘Data operations’ and select it from the menu. Then select the Parse JSON action
    undefined
    undefined
    Select the content field and feed in the following expression:
    decodeBase64(triggerBody()?[‘ContentData’])
    undefined
    Click ‘Use sample payload to generate schema’ and then paste in the following JSON sample payload.
    {“name”: “The Krusty Krab”, “websiteurl”: “http://thekrustykrab.com”, “numberofemployees”: 3}
    Click ‘Save’ on the command bar.

    Click ‘New Step’ on your process, then type in Dynamics 365. Select Dynamics 365 and then ‘Create Dynamics 365 record action’
    undefined
    undefined
    Click ‘Sign in’ and sign into your Dynamics 365 organization
    undefined
    Select your organization name, the target entity and then map each required field to the matching detail in the JSON payload.
    To map the nubmerofemployees integer data, put in the following expression:
    int(body(‘Parse_JSON’)?[‘numberofemployees’])
    undefined
    You should now have the following process defined:
    undefined
  3. Test by clicking ‘Run’ which will make you process start polling ASB.
    undefined
    Next, post a message with the required format to ASB queue.
    Note that if you left the trigger interval its 3 minutes default, you may wait up to 3 minutes for the message to be processed.
    You can do this using Postman and this useful collection

    Once Logic Apps picks the new message, you’ll see the process run
    undefined
    Finally, check the new Account record created in your Dynamics 365 organization
    undefined

    If you just set this listener up for learning purposes and you don’t actually need it running, make sure you disable your Logic App process so it will not burden your Azure budget for nothing.


Executing Web API Calls from Flow/Logic Apps

While writing my previous post regarding Flow as a scheduling mechanism,  I stumbled across this post demonstrating how to execute Web API calls from Flow.

Why would you want to execute Web API calls from Flow/Logic Apps?
While Microsoft Flow/Logic Apps support basic Dynamics 365 operations, there are many missing functions that can simplify common integration scenarios between these platforms: executing Custom Actions, triggering Processes, handling metadata and issuing complex queries.
Some of these problems can be worked around using the Command Pattern, but using the Web API from within Flow/Logic Apps provides a simple and powerful integration mechanism.  

In this post, I’ll demonstrate how to authenticate and execute Web API functions and actions from Flow (a similar process can be used with Logic Apps):

  • Execute a FetchXML query
  • Execute a Custom Action

The requirement used to demonstrate is again the automated weekly evaluation of Leads: once a week, any Lead which is older than 5 days and not rated hot is disqualified.
With this implementation approach, Flow is used for scheduling, query for target business records and applying a Dynamics 365 Custom Action to each business record. 

Prerequisite

  1. Have access to Microsoft Dynamics 365 online instance and Flow environment
  2. Register Microsoft Dynamics 365 online instance in Azure AD and have the Application Id key ready.
    Make sure you set the oauth2AllowImplicitFlow as described here.

Walkthrough

  1. Download and import Solutions

    Download and import this Flow solution into your Flow workspace.

    image

    image

    image

    Download, import and publish this unmanaged solution into your Dynamics 365 instance. It contains one Custom Action that will be executed from Flow using Web API. 

  2. Set Flow Settings

    Edit the newly imported Flow

    image

    Set the following keys with values to match your environment

    image

    image

    image

  3. Note the following settings

    This variable holds FetchXML query to retrieve the target Lead records.

    This variable holds FetchXML query to retrieve the target Lead records.

    This variable holds the target entity name as it is used with Web API

    This variable holds the target entity name as it is used with Web API

    This variable holds the target Custom Action to handle each Lead.
    Note that for unbound Custom Action, the Microsoft.Dynamics.CRM should be removed.

    This variable holds the target Custom Action to handle each Lead

    This action requests a token used to authenticate to Web API

    This action requests a token used to authenticate to Web API

    This action executes the FetchXML query

    This action executes the FetchXML query
    This action parses the query resulting records.
    If you change the FetchXML query to support a different entity or attributes, make sure you also change the JSON schema to support it

    This action parses the query result

    This action executes the target Custom Action for each Lead record returned by the query

    This action executes the Custom Action for each Lead record returned by the query

  4. Test your Flow

    After a successful run, Flow will display the number of affected records.
    In Dynamics 365, these records should appear as disabled now.

    image

    If your Flow fails on the RequestOAuth2Token action, try this solution

Implementation Notes 

  • I prefer authenticating using an Application Id and Secret via an App user rather than plain user credentials.