No, it's not what I mean.
1/ The ususal XSL transformation is executed using the XML payload or attachment,
2/ For each 'output-property' defined in the SU, a new XSL transformation is executed to defined its content. Inputs of this transformation are:
- input properties as global parameter,
- 'xsl-parameter' as global parameter,
- input XML payload
Why this feature ? To be able to transmit message properties when the SE XSL is used in a service chain orchestrated by the SE EIP (see the use-case described by SPVEOLIAE-60 replacing interceptors by native features). And more generally, component must be able to process message properties as the XML payload.
Note: About performances, these XSL transformations can be executed concurrently using a thread-pool of the component and java Future.
No, it's not what I mean.
1/ The ususal XSL transformation is executed using the XML payload or attachment,
2/ For each 'output-property' defined in the SU, a new XSL transformation is executed to defined its content. Inputs of this transformation are:
Why this feature ? To be able to transmit message properties when the SE XSL is used in a service chain orchestrated by the SE EIP (see the use-case described by SPVEOLIAE-60 replacing interceptors by native features). And more generally, component must be able to process message properties as the XML payload.
Note: About performances, these XSL transformations can be executed concurrently using a thread-pool of the component and java Future.
- input properties as global parameter,
- 'xsl-parameter' as global parameter,
- input XML payload
Why this feature ? To be able to transmit message properties when the SE XSL is used in a service chain orchestrated by the SE EIP (see the use-case described by SPVEOLIAE-60 replacing interceptors by native features). And more generally, component must be able to process message properties as the XML payload. Note: About performances, these XSL transformations can be executed concurrently using a thread-pool of the component and java Future.