Building a Common Message Solution with MongoDB at Vertafore

© 2014 Vertafore, Inc. and its subsidiaries.1

Building a Common Notification Solution with MongoDBJohn Gao | September 16, 2014

Steven Engelhart


Agenda

1 About Vertafore

2 Problem Statement

3 Design and Implementation

4 Product Demo


The Company

13,000,000 Producer Lifecycle Mgmt transactions

20,0000 customers use Vertafore

1,000 agencies adopted AMS360 in 2012

96 of the top 100 agencies use Vertafore

80 of the top 100 carriers use Vertafore

44 years transforming insurance

#1 software supplier to independent insurance

50,000,000 real-time transactions


Vertafore Solution Suite

Connectivity

4© 2013 Vertafore, Inc. and its subsidiaries.

Agency Carrier MGA/WholesalerContent and BusinessProcess Management

Content and BusinessProcess Management

Business IntelligenceBusiness Intelligence

Agency Management,Download and Real-timeDownload and Real-time

Policy IssuancePolicy Issuance

Producer LifecycleManagement



Comparative Rating Rating ManagementRating Interfaces

Reference Libraries Reference LibrariesReference Libraries

Producer Tools Producer ToolsProducer Tools

Content and BusinessProcess Management

Business Intelligence

Agency Management,Download and Real-time

Benefits Management

Connectivity


Breaking the Mold

• Need solutions to be re-usable

• Breaking the traditional SQL solution development pattern

• Freedom to choose the right technology to solve the problem


Design Goals

• Simple and Easy to User API

• Performance and Scalability

• Need to support both pull and push


Design Decisions

• “RESTful” web service using OData

• MongoDB for database

• RabbitMQ for queue to support mobile push


Why MongoDB?

• Performance and scalability

• No object to relational model translation

• Object model can be very flexible

• Supports all major platforms

• Excellent .NET and LINQ support


Overall Architecture


Object Model – NotificationMessage

• Type – admin, user, …• Priority – normal, critical, …• Author• Publisher• Recipient…


Object Model – UML Diagram


MongoDB Document – NotificationMessage


Message Service – Layered Diagram


public class NotificationMessagesController : ODataController { public IQueryable<NotificationMessage> Get(ODataQueryOptions<NotificationMessage> query); public async Task<NotificationMessage> Get([FromODataUri] string key); public async Task<IHttpActionResult> Post([FromBody] NotificationMessage message); public async Task<IHttpActionResult> Put([FromODataUri] string key, NotificationMessage entity); public async Task<IHttpActionResult> Patch([FromODataUri] string key, Delta<NotificationMessage> patch); }

Odata Layer - Controller


Domain Layer – Domain Services


public interface IRepository<T, U> { T Get(Expression<Func<T, U>> keyExpression, U key); IQueryable<T> Get();

T Create(T entity); T Update(T entity); bool Delete(T entity); }

Data Layer - Interface


public MongoRepository(MongoDatabase database, string collection) { Collection = database.GetCollection<T>(collection); } public T Get(Expression<Func<T, U>> exp, U key) { return Collection.FindOne(Query<T>.EQ(exp, key)); }

public IQueryable<T> Get() { return Collection.AsQueryable(); }

Data Layer - Implementation


private void InitializeStructureMap(IQueryRules rules) {DomainStructureMap.Map(container, (ConfigurationSection)ConfigurationManager.GetSection("NotificationCreatedEventQueue")); DataStructureMap.Map(container, ConfigurationManager.ConnectionStrings["MongoDB"].ConnectionString); });}

How Are The Three Layers Linked?


public static void Map(IRegistry container, ConfigurationSection notificationConfigurationSection) {container.For<IEntityEventProcessor>() .HybridHttpOrThreadLocalScoped() .Use<EntityEventProcessor>();

container.For<IDomainService<NotificationMessage, string>>() .HybridHttpOrThreadLocalScoped() .Use<NotificationMessageService>();}

Structure Map – Domain


public static void Map(IRegistry container, string dataConnection) { RegisterMappings(); container.For<IRepository<NotificationMessage, string>>() .HybridHttpOrThreadLocalScoped() .Use(r => new MongoRepository<NotificationMessage, string>(r.GetInstance<MongoDatabase>(), "Messages"));

container.For<IRepository<MessageHistory, string>>() .HybridHttpOrThreadLocalScoped() .Use(r => new MongoRepository<MessageHistory, string>(r.GetInstance<MongoDatabase>(), "MessageHistory")); }

Structure Map – Data


BsonClassMap.RegisterClassMap<NotificationMessage>(map => { map.AutoMap(); map.SetDiscriminator("NotificationMessage"); map.IdMemberMap.SetIdGenerator (StringObjectIdGenerator.Instance); });

BsonClassMap.RegisterClassMap<UserRecipient>(map => {

map.AutoMap(); map.SetDiscriminator("MessageRecipient_User");

}); // Other mappings omitted for clarity

Bson Class Map


MongoDB Replica Set


NotificationMessages.OrderByDescending (nm => nm.CreatedAt).Skip(100).Take(50);

NotificationMessages.Where(n => n.Id == "54132e3bf11fbc138c8f7448");NotificationMessages.Where (nm =>

nm.UserRecipients.Any(ur => ur.UserId == "35630")).OrderByDescending (nm => nm.CreatedAt).Take(10);

NotificationMessages.Where(x => x.Summary.Contains("New opportunity")).Take(10);

Usage Examples – Linq Queries


https://ServiceEndpoint/NotificationMessages()?$orderby=CreatedAt desc&$skip=100&$top=50

https://ServiceEndpoint/NotificationMessages('54132e3bf11fbc138c8f7448')

https://ServiceEndpoint/NotificationMessages()?$filter=UserRecipients/any(ur:ur/UserId eq '35630')&$orderby=CreatedAt desc&$top=10

https://ServiceEndpoint/NotificationMessages()?$filter=substringof('New opportunity',Summary)&$top=10

Usage Examples – Odata Queries


"op" : "query",

"ns" : "NotificationService.Messages",

"query" : {

"$query" : {

"UserRecipients" : {

"$elemMatch" : {

"UserId" : "35630"

}

} },

"$orderby" : {

"CreatedAt" : -1 }

},

Usage Examples – MongoDB Queries


Mobile Push Service

• Mobile device registration service– Register mobile device– Odata web service– Registration stored in MongoDB

• Windows service – Monitor queue message– Send message that has mobile destination to

Apple or Google for actual delivery


{ "_id" : "54174aad92d00721d4ef7315", "DeviceType" : "Android", "Token" : "<Device token goes here>", "AppId" : "SeattleDemo", "VssoId" : "35689", "VendorId" : "PipelineManager - Agent", "CreatedDt" : ISODate("2014-09-15T20:23:08.747Z"), "ModifiedDt" : ISODate("2014-09-15T20:23:08.747Z"), "DeviceData" : { "Data" : null }}

Device Registration – MongoDB Document


Mobile Push Service - Workflow


Overall Dev Experience

• What we liked– Very easy to setup– Great documentation and online resources– Great community support– No more mismatch of object to relational– Quick development cycle– Flexible schema works well


Overall Dev Experience

• Things that could have been better– 2.6 release felt to be rushed out. – No out of box encryption support– No MongoDB Management Service (MMS) on

windows


Operations Experience

• Hosting team was able to ramp up quickly

• Simple installation

• Quick and intuitive deployment of packages

• Easy to scale out


Push Notification Demo


Questions

Building a Common Message Solution with MongoDB at Vertafore

Technology

Transcript of Building a Common Message Solution with MongoDB at Vertafore