Business Events: Custom payload (III)

This is the third and last article in which we are going to talk about how to send a JSON with a custom structure through Business Events. In the previous article we saw a possible way to identify those business events that should undergo this new structure through the event catalog. Today, we will finally see how to modify the structure of the message sent for these events.

Modify the structure of the JSON sent through Business Events

The first step is going to be defining the data contract to comply with the JSON format that we need to generate. Let’s remember that the format in question should be something similar to this:

Note that the content of the “Data” node is the one that generates a data contract that inherits from the BusinessEventsContract class in a standard way. Therefore, what we will do is generate a data contract with the necessary attributes, with “Data” being an attribute of the JATBusinessEventContract type. (You can get more details about how to generate these objects in this article).

Therefore, our custom data contract should look like this:

Once we have defined our structure, we just need to collect the original message and transform it so that it complies with our format. After spending quite a bit of time debugging and learning how business events work when they are triggered, I reached the conclusion that the easiest and least intrusive way to do this was at the time of insertion into the BusinessEventsCommitLog table.

What the system does is launch the business event, create the message through the data collected in the data contract, serialize the information to generate the JSON, and once everything is ready, insert this information in the table above mentioned. This table is filled with the attributes collected in the BusinessEventsContract class, so we cannot change its structure if we want everything to continue working the same. Once inserted there, a process reads the data, and sends it to the corresponding endpoint.

Therefore, the solution is based on modifying the JSON already generated, so we will not interrupt the standard operation. To achieve that, what we do is extend the insert() method of the BusinessEventsCommitLog table, and just before inserting, we will modify the content of that JSON.

With this extension, we will send to generate our personalized format as long as the Event that has been launched is identified within the event catalog as one of our personalized events. If yes, we generate the new JSON as follows:

Basically, what we do is deserialize the JSON to get an object of the data contract that we are working with (we pass by parameters the name of the data contract to make it reusable), and once we have that object, we encapsulate it within the new data contract, which is re-serialized and is returned by the method to be inserted into the SerializedContract field of the BusinessEventsCommitLog table.

The rest of the process will remain 100% standard, therefore we do not need to extend anything related to the connection or the message handling from Dynamics 365 to the outside, which greatly facilitates the management of events.

With these latest modifications we are already prepared to be able to consume our personalized business events from any of the extremes that we have available.

As a result of these 3 articles, we have managed to generate a non-intrusive and 100% reusable solution. To generate new business events that comply with the same format, we just need to decorate those events with the attribute generated in the previous article.

Here I leave a link to github where you can find the complete solution.

I hope you find it useful, and of course I am open to all kinds of comments, criticisms and improvements. Greetings from home!