Configuration Container With Single Entity Message
The Connector you develop using the Messaging Framework must be able to parse messages received from the sending API. To parse the message, the Connector must understand the data structure for each message object. You can use a sample message from the sending API to configure the code that parses the inbound message by pasting the sample message as JSON in the item.cs file in your project and modifying the Connector.cs file to match the changes in item.cs. See Creating Message Classes for step-by-step instructions on pasting a message into your project.
This scenario requires a little bit more work because you need to configure how to extract the information from the message in the form of a Lambda expression or method.
In JSON the message might look like:
{"AccountName": "Acme, Inc.","MainContact": {"FirstName": "Abby", "LastName": "Aaron"}
}
The entire message appears to be an Account. If you are only interested in ‘extracting’ the person information, you can see that this message contains one person. If you paste JSON as Classes you start with:
public class Rootobject
{public string AccountName { get; set; }
public MainContact MainContact { get; set; }
}
public class MainContact
{public string FirstName { get; set; }
public string LastName { get; set; }
}
In this case you do need the container, but it is not well named, so change ‘Rootobject’ to ‘Account’. Because JSON does not have type names embedded, it infers the type to be the name of the Property ‘MainContact’ that contains it, which is not quite right here. You can say that the property named ‘MainContact’ for an Account is of type ‘Person’. So it would end up looking more like this:
public class Account
{public string AccountName { get; set; }
public Person MainContact { get; set; }
}
public class Person
{public string FirstName { get; set; }
public string LastName { get; set; }
}
This makes things clearer, both in the metadata and in the description of how to extract this value.
Modify the Connector.cs file to recognize the change made in the item.cs file.
protected override IDictionary<string, MessageDescription> RegisterEntities()
{ return this.Start.Register<Account, Person>(account => account.MainContact);
}
This overload of Register takes two type parameters <Account, Person> that indicate that Account is the type of the entire message, Person is the type of entity that this message becomes.
account => account.MainContact
The code shown above is the Lambda that says given an Account named account, return the value of the MainContact property. This is type checks to ensure that you are in fact returning a Person. A Lambda is a syntactical way to create an anonymous function in line. You could, if the function were more complicated or you preferred the syntax, write the exact same thing as:
public static Person ExtractPerson(Account account)
{ return account.MainContact;}
protected override IDictionary<string, MessageDescription> RegisterEntities()
{Func<Account, Person> extractPerson = ExtractPerson;
return this.Start.Register(extractPerson);
}
The code above simply creates a static function that does the same thing. Unfortunately, it is necessary in this particular case to declare the function as a Func with the specific types because C# inference cannot infer the type with the Register method, because it is overloaded. Although it is more verbose, this can be useful if the code to extract the value gets more complex. An alternative syntax is:
public static Person ExtractPerson(Account account)
{ return account.MainContact;}
protected override IDictionary<string, MessageDescription> RegisterEntities()
{ return this.Start.Register<Account, Person>(account => ExtractPerson(account));
}
In this case, the Lambda syntax is used again, but putting the majority of the complexity into a named function.
See