Hmmmm...
it seems you did things in the right way... so my two last comments
were not probably correct (I mean the answers about the transactional
behaviour and about the parameters passed in the eca), I'm sorry for
this. I will do more research on this in my spare time but in the
meantime I'll try to 'refund' you with a better advice :-)
Back to your original question:
This is the code from your original message:
<simple-method method-name="myown.updateWorkEffort"
short-description="Update Work Effort and then Work Instruction">
<set-service-fields map-name="parameters"
service-name="updateWorkEffort" to-map-name="updateWorkEffortParams"/>
<call-service service-name="updateWorkEffort"
in-map-name="updateWorkEffortParams">
<default-message>Work Effort successfully
updated.</default-message>
</call-service>
<check-errors/>
<!-- Do my own stuff here. Like updating entity NoteData, for eg. -->
</simple-method>
I'd suggest to create another custom service that performs "your own
stuff here. Like updating entity NoteData...", let's call it
myown.updateWorkInstructions: in it's service definition you can put all
the relevant parameters (a subset of the parameters of the
myown.updateWorkEffort service).
After this is done, the myown.updateWorkEffort service can be
implemented in this way:
<simple-method method-name="myown.updateWorkEffort"
short-description="Update Work Effort and then Work Instruction">
<set-service-fields map-name="parameters"
service-name="updateWorkEffort" to-map-name="updateWorkEffortParams"/>
<call-service service-name="updateWorkEffort"
in-map-name="updateWorkEffortParams">
<default-message>Work Effort successfully
updated.</default-message>
</call-service>
<check-errors/>
<set-service-fields map-name="parameters"
service-name="myown.updateWorkInstructions"
to-map-name="updateWorkInstructionsParams"/>
<call-service service-name="myown.updateWorkInstructions"
in-map-name="updateWorkInstructionsParams">
<default-message>Work Effort Instructions successfully
updated.</default-message>
</call-service>
</simple-method>
Does it make sense?
Jacopo
PS: If you are in the mood of doing some experiments, another
alternative solution is to create a new service of type service-group
(you should find at least an example of this in the system).
Jonathon -- Improov wrote:
Jacopo,
Sorry to bother you again.
I seem to have problems with both the service eca method and the chained
request method.
The eca method seems to give me the triggering service's parameters. For
eg, say I have a service B triggered on eca by service A. Service B will
receive only the parameters passed to A. Ie, it seems that the
invocation of service A:
1. Creates a local context that contains only the parameters that
service A expects,
2. Passes this same local context on to service B.
The chained request method did not roll back the 1st service when an
error is encountered in the 2nd service.
In the 2nd service, I threw a deliberate error like this:
<add-error>
<fail-message message="Deliberate error"/>
</add-error>
<check-errors/>
Maybe I didn't throw the error correctly?
The chained requests:
<request-map uri="UpdateRoutingTask">
<security https="true" auth="true"/>
<event type="service" invoke="updateWorkEffort"/>
<response name="success" type="request"
value="UpdateRoutingTaskPlusMore"/>
<response name="error" type="view" value="EditRoutingTask"/>
</request-map>
<request-map uri="UpdateRoutingTaskPlusMore">
<security https="true" auth="true"/>
<event type="service" invoke="myOwn.updateWorkEffort"/>
<response name="success" type="view" value="EditRoutingTask"/>
<response name="error" type="view" value="EditRoutingTask"/>
</request-map>
Thanks for your time.
Jonathon
