Thanks very much, when I have something working I will make it less
specific to my needs and post an article, or create a Synapse sample.
All the best,
Wayne
On Wed, Apr 16, 2008 at 9:31 AM, Ruwan Linton <[EMAIL PROTECTED]>
wrote:
> 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"
>
