Should I reuse message classes across different Business Operations or create one per flow?
When building a Production, should I create separate message classes for each integration flow, or is it acceptable to reuse generic request/response classes across different Business Operations? I'm trying to understand how to keep things organized as the number of integrations grows.
Comments
It is acceptable to reuse message classes across different Business Operations. A Business Operation can accept many kinds of request messages, and the supported request types are defined at the method level through the operation’s message map rather than as a single operation-wide request/response pair. The message map can contain multiple MapItem entries, each matching a different request class to a different method, and if no entry matches, OnMessage is called. [1][2]
A message handler method is defined with a specific request class and response class signature:
Method Sample(pReq As RequestClass, Output pResp As ResponseClass) As %Status {}
This shows that request/response classes are tied to individual handler methods, not necessarily uniquely to an entire Business Operation. [2]
If you want to keep things organized as integrations grow, documenting the operation’s intent and interface is considered best practice, especially when they are not trivial. One discussion also notes that developers need clearer visibility into supported request and response classes, and shows an approach to expose those through helper properties derived from the message map. [1]
There are also examples showing both patterns in use:
- a generic Business Operation used with generic request/response classes, where flexibility is prioritized [3]
- generated dedicated Business Operations with dedicated request/response message classes, where direct field-level message definitions are “a great help” when using the request builder [3]
So the documented material supports both approaches: reuse generic request/response classes when that fits your design, and create dedicated message classes when clearer, more direct interfaces are helpful for maintainability and tooling. [1][3][2]
Sources:
I think this is something that heavily depends on your use case, but in general I would just stick to typical Object-Oriented Programming best practices (e.g. SOLID) and try to aim for a level of abstraction that fits your application. If your different integrations use the same types of information, then having them reuse the same message classes makes sense to me.
For better monitoring (e.g. the "Activity Volume And Duration") it is recommended to use specific message request and response per component.
Using specific messages will also help with ensemble messages storage if different components are having different properties for request/response
Hi @Aziz Cotrim
One approach I use, to take advantage of both what @Nick Petrocelli said and what @Yaron Munz said, is to create a message that will be the common basis for defining the properties. I define it as abstract and create specific messages inheriting from this base class, adding the %Persistent class to the inheritance list. This way, the storage will be individual for each message, but maintaining a single definition.
Take a look at my Interopway Rest project. I use this approach.