Third-Party Service Integration Approaches

Hi guys,

I have a new requirement for my app which requires me to make a REST call to a third-party system. The process needs to fire when the createUser handler/method is called in our app, and needs to pass a subset of the user info that exists in the RC. I am writing a CB plugin that interfaces with the third-party system. (which I hope to post on Forgebox at a later date)

Currently I am using BeanFactory.populateBean() with ORM in my handler to create the user and persist the user data to the database. I am wondering if you could share your opinions on best practices/your approaches as to where the third-party REST integration should occur. Here are my thoughts as to where it may be:

1. Load plugin into handler and make REST call before/after createUser call
2. Load plugin into model and execute call in PostInsert method
3. Other approaches??

Thanks guys. Appreciate your thoughts on this.

Nolan

If this is the only place your third party call is needed I would add it to your model. However, if you believe you may need to take more steps in the future when a “New User Event” occurs, you may want to create a custom interception point and then make this happen in an interceptor. I could easily see additional processes kicking off from the interceptor layer.

Aaron

Thanks Aaron,

I was leaning toward the model approach as well. I’m not sure why I didn’t think of the Interceptor, and agree that this would make additional service integration a lot easier.

I guess my overarching concern would be how to best design and catch errors in the event that the call to the third-party services were to fail for whatever reason. Essentially I need to keep both systems in sync. Is it possible to have an aroundHandler on an interception point? If so I could wrap each interception point in a try/catch (within the aroundHandler) and trap any errors that occur with the third-party service and queue them for later. Does that seem like a valid approach?

Much appreciated.

Nolan

Sounds like this is more of a work queue type of a task… Unless it has to be instantly synced I would opt for the following (instant sync may warrant a new thread).

I would create a system to manage tasks and generate a task entry for this event. Tasks can be just simple records in your MSSQL database–or MongoDB is a perfect candidate for this stuff as it can eaisly support multiple workers without allowing overlapping–and have some workers that are scheduled to run every N seconds to do this work. Such a system would bring this process offline so it does not block the response to the user. Furthermore, if the sync fails with your third party via your Gateway your worker can have another shot at getting the job done since the task will still have your the queue (and you wont loose anything). If the process errors four or five times (I’d tick some error counter within the record) then perhaps it can notify you via e-mail or text message (or create a Hoth :slight_smile: so you can intervene.

Aaron

Hi Aaron,

Thanks for your feedback on this. I like the MongoDB approach, although I’ve yet to do any dev with Mongo yet. :slight_smile: I’m going to read up on it now.

Cheers,

Nolan