Asynchronous messaging and Event driven architectures are the building blocks of a truly scalable system, where the services can talk to each other and can scale up and down independently. Where, the outage of one service do not impact the working of others.
Suppose we have the following embedded marketing form, submitted by the user with Remember Me checked (required for Personalized Page as well as Prefill to work)
Next time when the user visits the page, using the Personalized Page’s Script, we can have this value fetched from the cookie as shown below.
Here we can use the same personalized page script on other pages in the same authenticated domain/website to retrieve the values from the cookie.
For that, we just need to have the website’s div tag to be placed on that page, as shown below. We can get from that from the website record created and it will track the visit as well.
To hide the Marketing form on the host page – we can use afterFormRender
To submit the Marketing form on the host page –
If we are setting a non-existing value for an option set field in the formSubmit event, it will be treated as blank before submission and the blank value will be passed. However if the field is Required then validation will kick in and the form will not get submitted.
Last month, one of my friend called me and asked me if I can help him integrating Dynamics CRM with an on-premises line of business (LOB) application using Azure Service Bus. He was a SharePoint expert, with reasonable experience of Dynamics CRM and Azure Service Bus also and he had to develop a POC for his client to win a project. By then I didn’t have any experience with Microsoft Azure. So, I looked it as an opportunity for me to learn something new, the Microsoft Azure Service Bus. I spent few days studying and watching concepts and demos regarding Microsoft Azure, Azure Service Bus and Dynamics CRM-Azure integration. Eventually, we both started working on the project. The project had few other challenges too, but mainly I learned enough about Azure Service Bus and Dynamics CRM integration while working on this project. In this two part series of blog post…
Do you know the Azure-aware plugin? In short, we can create a simple plugin that invokes Azure Service Bus that enables us to do the Publisher-Subscriber model. In this blog post, we will try to makeAzure Service Bus, Dynamics CRM Service Endpoint, andCRM Pluginfor creating the queue. While for the processing part (subscriber), we will createCloud Flowthat will listen to the queue + insert a row on the google sheet.
Creating Azure Service Bus
You can go to your portal.azure.com >Service Bus> click theCreatebutton. On that page, you can fill in theSubscription, create/select theResource group, fill theNamespace, set theLocation, and set thePricing tier(I choose Basic for the demonstration purpose which is the cheapest tier). After that, you can hit theReview+createbutton and proceed to create the resource.
This is the next level of my previous post on Azure service bus integration with CRM. If you haven’t gone through it already, I would highly recommend you to go through it first over here as whatever we are going to do here in this post is kind of an extension to my previous one.
So, in the last post, we saw how we can pass the CRM entity information to ASB (Azure Service Bus) whenever it got created/updated/any other plugin actions happened. And you must have noticed by now that it would be an asynchronous job for us, meaning CRM would be in ‘fire and forget’ mode. All it knows is it has dropped a ‘Message’ in a Queue, it doesn’t know when it got picked up and when it got processed and who picked it up etc. In some cases this might be the exact behavior we are…