Question
National Account Service Company
US
Last activity: 8 Aug 2018 11:09 EDT
Integrate from one Pega Customer Service application to another Pega Customer Service application
Hello,
We have a requirement where we want to integrate from one Pega Customer Service application to another Pega Customer service application. We still are gather more detailed requirements on that, but for now we are looking at different design options that are feasible. Appreciate if anyone can tell me what are the recommended ways to integrate two customer service applications. Some design patterns that i am thinking might work are:
1.) Using Federated Case Management, where the case is defined in the destination Pega CSR application and it gets created and worked on from client/source Pega CSR application. I believe this would require a Web-Mashup license, as well as changes on client Pega CSR application as well as in destination Pega CSR application.
2.) Having an batch agent defined in the client CSR, that will invoke a REST Service hosted on the destination system. The agent will be scheduled to run once a day/every 12 hours.
3.) Having a batch agent defined in the client CSR to write to a FTP Server location on the destination server. Define a file listener on the destination Pega application to process the file contents. The response is then written back to client system (with a FTP Server location defined there).
Looking forward to some information if there are other ways to integrate the application, other than the design patterns above. Are there any recommended ways. Appreciate the help.
Thanks,
SG
National Account Service Company
US
Let me set the premise, before getting into the business requirement:
A CSR user in one state say NY gets a call from a member who has an insurance from a different state (say CA) but is in NY when he has a health issue. So he calls the CSR in NY to address those issues. His health insurance is from a plan that covers multiple states across the country. Each state CSR's are working in different instances of Pega application for Customer Service. So the CSR from NY is working on a different instance of Pega Application for customer health care as compared to a CSR in CA.
The business requirement is, when a call is received from out of state members, CSR from the calling state, also referred to as host state/plan (which in this case is NY), has to create work/case/interaction/intent for the home state/plan (which in our case is CA). The CSR user who creates the work should be able to manage/track the work created. The actual work will be done by the home plan CSR user.
The different design patterns that i am thinking that might work here are:
Let me set the premise, before getting into the business requirement:
A CSR user in one state say NY gets a call from a member who has an insurance from a different state (say CA) but is in NY when he has a health issue. So he calls the CSR in NY to address those issues. His health insurance is from a plan that covers multiple states across the country. Each state CSR's are working in different instances of Pega application for Customer Service. So the CSR from NY is working on a different instance of Pega Application for customer health care as compared to a CSR in CA.
The business requirement is, when a call is received from out of state members, CSR from the calling state, also referred to as host state/plan (which in this case is NY), has to create work/case/interaction/intent for the home state/plan (which in our case is CA). The CSR user who creates the work should be able to manage/track the work created. The actual work will be done by the home plan CSR user.
The different design patterns that i am thinking that might work here are:
1.) Using Federated Case Management, where the case is defined in the destination Pega CSR application(home plan) and it gets created and worked on from client/source Pega CSR application. I believe this would require a Web-Mashup license, as well as changes on client Pega CSR application as well as in destination Pega CSR application.
2.) Having a batch agent defined in the client CSR (host plan), that will invoke a REST Service hosted on the destination system (home plan) to create a case/work/interaction. The agent can be scheduled to run periodically. Additionally have a service exposed in the home plan/state application to retrieve the current status of all the work. This looks like the best option in my opinion without any additional licensing cost and seems very straightforward to implement.
3.) Having a batch agent defined in the client CSR to write to a FTP Server location on the destination server. Define a file listener on the destination Pega application to process the file contents. The response is then written back to client system (with a FTP Server location defined there). This is batch mode of processing the work with a significant delay in executing it.
Please let me know which option is most recommended from Pega product framework point of view. Appreciate the help.
Regards,
Swami Gopalan
Pegasystems Inc.
US
Hello Swami,
So you want the interaction to reside in both the NY and CA systems? I would say, if you want the CSR to launch the CA system in more of a fire and forget sort of way, you could use a snapstart URL to launch the CA system, work the case, and then log out/close the window when finished. The downside is that your NY operator won't be able to report on that case without you doing something clever with your reports. Assuming each system has access to all 50 databases you could do a join across all of them. Otherwise, FCM should work, though I don't the details around licensing, so you would need to sort all that out.
Certainly passing data around via a rest service or batch job or what have you, should also work, just not in real time. But again, without knowing all of the ins and outs, it's hard to suggest a "best" practice, but here's some things for you to consider.
Thanks,
Mike
National Account Service Company
US
Yes. The Host plan (which in our case is NY), should be able to track what happened to those interactions. But the actual work on that interaction is done by an operator/user in CA. Since the call was received by a NY CSR, he needs an interaction so that it is reported as a productive work against his time.
I have not used Federated Case Management before, but it seems like this might be a perfect use case for it to be used. It will require some design configurations on the Pega Applications hosted on both states (NY and CA) with setting up a FCMR Repository. The only disadvantage i see using Federated case management, it becomes a Pega specific solution design. Which means this works only from one Pega application to another Pega application.
Building a RESTful services mode might take more effort, but will ultimately make that application technology agnostic, allowing any RESTful client to call the Pega Application.
I would like to understand if there are any other ways to do this integration? Does Federated case management has any other advantages that i may have missed.
Appreciate the help.
Thanks,
Swami
Pegasystems Inc.
US
Swami,
Is it an absolute requirement that each state be on their own app server/DB? Presumably if they are all using PegaCS, they are doing largely the same work, with some state specific differences. Would that be exactly what Pega's situational layercake is for? If you have a single PegaCS system with your org specific layer, and then state specific layers on top and things like circumstancing your rules to allow operators in California to work cases in New York. It sounds like you are making this more complicated than it needs to be. Otherwise, yes FCM can work, but will require a bit of set-up and work on your end. And you could definitely build your own REST services, in which case you are doing a lot of custom work that you will own the ongoing maintenance of. It will mean you can open up the interfaces for other, non-Pega applications, if that's a requirement, although discussing how best to do that becomes a much larger conversation and deeper understanding of the other applications you are interfacing with and what work you do/don't want to do.
Thanks,
Mike