Page 48 - MSDN Magazine, March 2018

Figure 2 Reading Messages from a Topic
and handling the OnMessage event that’s raised by the subscription client when a new message is available in the topic. The received message contains an object sent by an external application, say a vendor sending product details. This object is then mapped to an entity in my system, using the entity map, and if the entity already exists in my database, I update it; otherwise I create a new one.
The mapping process, implemented in the EntityMap class, consists of two important steps:
1. It creates a map between the object in the external system and the entity in my database. This map identifies the external object by pairing the system name (such as “ERP,” “Vendor1,” “Vendor2”) with the primary key. The mapped entity is identified by its type in my application (Product, Customer, Order) and its ID.
2. It builds an entity record using the properties of the exter- nal object. This is the custom merge logic, which can be as easy as using a library like AutoMapper (automapper.org) to map objects.
As shown in Figure 3, the object-entity map is a dictionary that associates a system name-primary key pair to an entity type-entity id counterpart. An object in an external system is identified uniquely by the combination of system name and primary key, whereas an entity in my application is identified by the combination entity type and entity id.
The map is populated by retrieving the system name and pri- mary key from the properties of the brokered message, and then building an entity with AutoMapper, as shown in Figure 4.
A brokered message can be enriched with any additional prop- erty, which the publisher application should set before sending the message to the ESB:
public async Task SendMessageToServiceBus(object obj) {
public class Aggregation {
public void Execute() {
var client = SubscriptionClient.CreateFromConnectionString( connectionString, topicName, subscriptionName);
client.OnMessage(message => { ProductEntity product =
EntityMap.Instance.MapToEntity<ProductEntity>(message);
// Persist the product
var exists = Find(product.Id) != null; if (exists)
Update(product); else
Create(product); });
}
The Aggregation Pattern
The second requirement for my e-commerce platform is to share information about products from external systems and consolidate it into the Web portal. The direction of the data flow in this case is opposite to that of the broadcast pattern. The requirement now is to aggregate data from various sources into a single place. A simple approach would be to import data directly, point to point, from each source into the e-commerce application. But this isn’t a scalable solu- tion, as it implies building a different connection for each external system that’s sending data to the target repository. Instead, by aggre- gating data in one process through an ESB, I eliminate the need for multiple one-way integrations, and mitigate concerns about data ac- curacy and consistency as data is processed in an atomic transaction.
What arises, though, is the challenge of merging data into a sin- gle entity without duplicating information or, worse, corrupting it. It’s often necessary to implement custom merge logic as part of the integration process, in order to track aggregated records sourced from different systems and store them in one or more entities in the application. I need a mapping table to associate record IDs in the different source databases with the entity ID in the target database. This mapping table is typically persisted in a high-transaction database, and updated by the data merge custom logic during the aggregation process.
As with the Broadcast pattern, the implementation of this integration pattern also reflects publishing/subscribing to an Azure Service Bus topic, with the difference that, in this case, my e-com- merce application is the target system receiving data (subscribing to a topic) from other source systems via the ESB. The overall solu- tion also needs to use some data merge logic and data mapping to track source record IDs and the entity ID at destination.
As you can see in Figure 2, reading messages from a topic con- sists of creating a subscription connection (SubscriptionClient),
Figure 3 The Object-Entity Map
var client = TopicClient.CreateFromConnectionString(connectionString, topicName); var message = new BrokeredMessage(JsonConvert.SerializeObject(obj));
message.Properties["SystemName"] = "Publisher System Name"; message.Properties["PrimaryKey"] = "Object Primary Key";
await client.SendAsync(message);
The Bidirectional Synchronization Pattern
Let’s look now at the third requirement: adding location tracking to shipped parcels. In more generic terms, I want to augment the attribute of an entity with additional attributes that are provided by a more specialized external application. For this reason, this pattern is sometimes referred to as the Augmentation pattern.
Systems involved in a bidirectional synchronization process with a third-party line-of-business application can extend their functionality beyond their boundaries. As an example, Dynamics
365 is a customer relationship management plat- form (and much more) that integrates natively with SharePoint for enterprise document manage- ment. Dynamics 365 still remains the master data source for all records, but documents are stored in SharePoint as an extension of entities in the CRM sys- tem. Basically, once two systems are in bidirectional sync, they behave as one system while still retaining
}
System Name
Primary Key
Entity Type
Entity Id
ERP
ABC012345
Product
FAE04EC0-301F-11D3-BF4B-00C04F79EFBC
Vendor 1
1000
Product
FAE04EC0-301F-11D3-BF4B-00C04F79EFBC
ERP
ABD987655
Product
2110F684-C277-47E7-B8B9-6F17A579D0CE
Vendor 2
1001
Product
2110F684-C277-47E7-B8B9-6F17A579D0CE
42 msdn magazine
Azure Service Bus