Question
· Apr 15, 2021

Best practices for implementing REST Interfaces in an IRIS Production

Hello Everyone,

We are currently in process of implementing REST APIs using IRIS and we are also looking at using Intersystems API Manager. 

Our aim is to implement a Microservices Architechture where Services are small in size,  bounded by contexts, autonomously developed, and independently deployable. 

We are following a spec first approach where we are first defining the API specs into Swagger Hub and using IRIS API Management Service to build the REST classes i.e. the Specification class, Dispatch class and Implementation Class.

Methods in Implementation class invoke a Business service in IRIS Production and then a Business process and an Operation. We are creating a Business Service per resource e.g. "Patient" but we want to keep the Business processes and Operations as discrete as possible hence we are creating a BP and BO per Action on a Resource. 

So for example for a "Patient" resource if the possible actions are Add, Update, Delete, Read and Search. In the IRIS production, we have one Business Service, 6 Business Processes (1 for each Action plus one for routing) and 5 Business Operations.  (Shown in the screenshot below). 

This would mean that if we have 50 different resources and each resource had these basic 5 Actions, we'd end up with 250 Business processes and 250 Business Operations.  Our assumption is that  the concern around spewing too many underlying processes (for each BP and BO) will be addressed by relying on Actor Pool for low traffic interfaces and allocating more resources/processes to high traffic ones.

Can I please ask for advise on whether this is the right approach or not? If not, what are the concerns and how can we address those and what is the better approach?

Thanks heaps.

Utsavi

Product version: IRIS 2020.1
Discussion (8)1
Log in or sign up to continue

Microservices are supposed to run separately with an ability for scalability, failure recovery, and be independent of the running environment. And the major side effect of it, microservices are language-independent.

And IRIS production, not the platform for microservices at all. Just only one production, limited by one server, if you will need to add some more items to it, you have to update the entire production. Yes, it will be possible to scale services when needed, but it still will be limited by the resources of the server where the production running. There are no easy ways how to automatically recover Production after failure. 

So, nowadays, would recommend trying Kubernetes as a platform for microservices, each microservice could be written in any supported by IRIS language (nodeJS, .Net, Python, Java). With IRIS itself running in the mirror for high availability.

Speaking about HealthCare application, why would you even decide to implement some own way, when FHIR already covers most of the things you would need?

Hi Dmitry,

Thank you for reply :)

>>>Speaking about HealthCare application, why would you even decide to implement some own way, when FHIR already covers most of the things you would need?

Would you mind elaborating on this last statement please? I am not sure what you mean. 

We are writing specifications for our API following the FHIR standard. 

Utsavi

ah well, in our case IRIS is acting as an ESB. Data doesn't live in IRIS. We are calling out to other systems to get the data e.g. Patient Administration System or Health Provider Directory.  In this case the other systems may or may not support APIs in which case we would query them using ODBC Adaptor, transform data to FHIR compliant json schema in IRIS and return to the client.

So, in this case, In fact, if you are not going to migrate that data to IRIS in the end, I see no reasons to use IRIS for such data. And microservices has written in some other languages, really a better way. 

Would it be possible to synchronize the date from other services with IRIS? So, your patient data still will be there, and backed up in IRIS, with FHIR endpoint. So, in this case, you can use IRIS Production to do this particular task.

Let me elaborate a bit more on Dmitry's suggestion.  IRIS for Health has a full FHIR server capability built-in.  Rather than implement the API yourself, and have to keep up with the changing FHIR versions, you could use that.  Now where the data comes from is a separate issue.  For this you can use the interoperability of IRIS to reach out to your external systems to supply the data needed to complete the FHIR request.  This stays with your use case of IRIS as an ESB to the rest of your environment.  You can still use the InterSystems API manager to provide access to the service and mange that inteface.

Generalize.

1. You can have 1 BP/1 BO called GET resource which gets:

  • resource id
  • resource type

And based on that information constructs the required JSON.

2. If BP only proxies requests to BO you can skip BP and call BO straight from BS.

Check out RESTForms2 - it does something similar (CRUD over classes) and there's only 4 handlers for all classes.