Jacopo,
> 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 :-)
Maybe I came across to you in a wrong way before. Please don't say sorry for that "try-this?"
advice. I'm just glad you find the time to "experiment together" with me. I'm not really a robot
with no heart, asking humans "why do you need to sleep, can you please research for days then
answer my question ONCE and ACCURATELY?". I'm not that bad a monster. :P
> 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?
So, service "myown.updateWorkEffort" will contain a superset of input parameters, both for service
"updateWorkEffort" and for service "myown.updateWorkInstructions"? Yeah, that's what I'm currently
doing too.
Your suggestion to put the logics "update work instruction" in a separate service
"myown.updateWorkInstructions" will properly modularize things, such that I can call service
"myown.updateWorkInstructions" separately from some other place.
Wrapping the 2 services "updateWorkEffort" and "myown.updateWorkInstructions" together into
service "myown.updateWorkEffort" will certainly wrap it all up in a single ACID transaction.
Yeah, that makes sense. Thanks.
> 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).
Ok, I'll try that. Thanks for pointing it out.
Jonathon
Jacopo Cappellato wrote:
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
