Hi Wayne,
According to your problem here is the optimized solution that I can see;
- Inside an in mediator Clone the message in to two messages and give
the messages to two sequences (lets say sequence A and B)
- Inside sequence A put a callout mediator after an XSLT mediator to
transform the message to relevant format (or you can use a custom mediator
to do the callout), then set the property "RESPONSE" on the axis2 level to
make it an outgoing message
- Inside sequence B set the property "RESPONSE" on the axis2 level to
make it an outgoing message
- On the out mediator put a XSLT mediator to wrap the messages into a
wrapping tag
- Then put an aggregate mediator to aggregate the parent message and
the response from the callout using the wrapping element
- Now you will have a message with both the first incoming request and
the response from the callout mediator aggregated inside the wrapping
element you used in the transformation above
- Then use the iterate mediator to iterate over the child elements
make sure to use the preservePayload=true to preserve the whole payload on
the iterated (splitted) messages (this will provide number of identical
messages according to the number of child elements in the message)
- Now again use an XSLT mediator to include the required callout
response contents to the child elements to for the new messages.
- Then use the normal send mediator to invoke the service with child
messages.
following is an abstract config that has to be used, and you can replace all
the XSLT mediators with script mediators with groovy, also you can write
your own mediators to handle any of these actions if required.
<defnitions>
<in>
<clone><target sequence="A"/><target sequence="B"/></clone>
</in>
<out>
<xslt ... [to add the <wrapper> tag as a wrapping]/>
<aggregate expression="//wrapper"/>
<iterate expression="[child-element]"><target sequence="final"/></iterate>
</out>
<sequence name="A">
<xslt />
<callout/>
<property name="RESPONSE" value="true" scope="axis2"/>
</sequence>
<sequence name="B">
<property name="RESPONSE" value="true" scope="axis2"/>
</sequence>
<sequence name="final">
<xslt />
<send/>
</sequence>
Hope this will help you.
If you want to block a particular message you can do so by evaluating the
following code over that message;
OperationContext opCtx
= ((Axis2MessageContext)
synCtx).getAxis2MessageContext().getOperationContext();
if (!continueParent && opCtx != null) {
opCtx.setProperty(Constants.RESPONSE_WRITTEN, "SKIP");
}
Thanks,
Ruwan
On Wed, Apr 16, 2008 at 12:26 PM, Wayne Keenan <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> The incoming message to my proxy contains a parent record with many child
> records.
> I need to send the parent record to an atomic create record service and
> with
> the response from that atomic service I extract a key which I then
> subsequently need to use when sending the child records to further atomic
> create services.
>
> What I can't not see is how to easily preserve the original message AND
> wait
> for the 1st message to complete, e.g. a clone isn't viable as the
> sequences
> are triggered in parallel and I need to wait for the parent ket from the
> 1st
> create.
>
> Would one approach be to:
>
> 1. insert a generated unique message id on input, for use later in the
> proxy
> only
> 2. clone the message, send the 1st to the create for the parent, keeping
> the
> 2nd untouched
> 3. aggregate based on id created in #1
> 4. take the unaltered child messages from the 2nd in #2 and use for the
> child creates
>
> To me that seems inefficient (I will have approx. 6 'types' of child
> records), so I'm wondering if mm overlooking something and/or going
> against
> the grain.
>
>
> Thanks
> Wayne
>
> On Tue, Apr 15, 2008 at 9:51 AM, Ruwan Linton <[EMAIL PROTECTED]>
> wrote:
>
> > Hi Wayne,
> >
> > You should have a look at the callout mediator [1] and also this [2]
> case
> > study, which covers some ground and do something similar. Also you can
> use
> > the SynapseEnvironment.createMessageContext() to get a new message
> context
> > created. You can use java inside groovy and hence this call will be
> > possible
> > inside groovy as well.
> >
> > Hope this will help.
> >
> > [1] - http://synapse.apache.org/Synapse_Samples.html#Callout
> > [2] - https://wso2.org/library/3325
> >
> > Thanks,
> > Ruwan
> >
> > On Tue, Apr 15, 2008 at 1:57 PM, Wayne Keenan <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Hi,
> > >
> > > I think I might be pushing/abusing mediators, by doing more that
> message
> > > manipulation, I'm trying to call endpoint from within a script, and
> > would
> > > be
> > > grateful for some advice.
> > >
> > > Here is the setup:
> > >
> > > 1. Synapse
> > >
> > > a) publishing a predefined WSDL of 'composite' services. e.g.
> > > createTroubleTicket.
> > > b) a mediator chops up incoming SOAP Payload XML into parent child
> > records
> > > c) the mediator calls (external) lower level atomic services (e.g.
> > create
> > > record) for the parent
> > > d) the mediator needs to either calculate child id (e.g. sequential
> > index)
> > > or use the result of parent ids created at runtime
> > > e) the mediator calls (external) lower level create record for the
> > > children
> > >
> > > 2. RESTful server for the (external) Atomic services
> > > a). create record in a DB (not JPA, uses propritary API to create 1
> row
> > in
> > > an underlying DB)
> > >
> > >
> > > I am writing a Groovy mediator to take the parent and child records
> and
> > > then
> > > call the atomic service endpoitns using somehtin glike:
> > >
> > > def createEP = mc.getEndpoint("SOME_API_CREATE")
> > > createEP.send(newMc)
> > >
> > > I've basically got 1a,1b & 2a working, but for 1c-e trying to create
> > the
> > > new MessaceContext ('newMc') is perhaps telling me I should not be
> doing
> > > this?
> > >
> > > I wanted to avoid 'programming in XML' via the declarative Synapse
> > > mediators, but perhaps I will have to?
> > >
> > > Regards
> > > Wayne
> > >
> >
> >
> >
> > --
> > Ruwan Linton
> > http://www.wso2.org - "Oxygenating the Web Services Platform"
> >
>
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
