We come across some repetitive steps when developing common mediation scenarios due to some limitations in current EI/synapse capabilites/syntax. I think if we can introduce some enhancement like below, we can minimize such situations:
1) Set service invocation related details within call/send mediators (or endpoints) Currently some details related to service invocations such as content type, HTTP headers, whether the message is out only or not, etc are set using property or header mediators. It's is better if such details can be set within call/send mediators as it brings all invocation related details to a single place. Also, it will simplify the flow by reducing the number of mediators used for service invocations. 2) Ability to set response to a property within the call mediator Currently invocation response is set as the body (i.e. message context) and before invoking another service current body has to be assigned to a property. Therefore, in service chaining scenarios, many additional enrich mediators have to be used to copy body to a property before each invocation. If we can set the response to a property within the call mediator itself, such additional mediators can be avoided (similar behavior is introduced in the new dscall mediator discussed in "[Architecture] Data Services Call Mediator"). This is true for setting the request payload as well. It is better if we can specify a property value as the request payload (better if we can specify a jsonpath against a property) instead of always picking the body as the request. 3) Better support for working with property values Once we store some content in a property, we may want to modify or access it using xpath, jsonpath, etc. An example would be to call two services S1 and S2, and store their responses in two properties P1 and P2. Then we may want to construct a message (e.g. using payload factory mediator) by combining certain values (e.g. extracted from jsonpath) from both P1 and P2. I couldn't find a way or an example to do this directly. May be we can add this along with the effort for improving json support. 4) Better support for manipulating json payloads Support for common use cases such as setting a value of given jsonpath (in message context or property) and adding/removing/modifying json array elements will be useful. Regards, Chathura
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
