You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@synapse.apache.org by Wayne Keenan <wa...@gmail.com> on 2008/04/15 10:27:38 UTC
Composite Services Architectural question
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
Re: Composite Services Architectural question
Posted by Wayne Keenan <wa...@gmail.com>.
Thanks for the pointers I will have a read.
I did find the env api call you mention, for reference here was my
(buggy/incomplete) code:
static void mediate (mc) {
def env = mc.getEnvironment()
def newMc = env.createMessageContext()
//newMc.setEnvelope(mc.getEnvelope())
//def newScriptMc = new ScriptMessageContext(newMc, new
DefaultXMLHelper())
//newMc.setPayloadXML('''<mymessage/>''')
def createEP = mc.getEndpoint("API_CREATE")
createEP.send(newMc)
}
I ran out of time last night, but seemed to have to jump thru hoops to get
to an XMLHelper, which I never got to work properly.
Thanks again for the links,
All the best
Wayne
On Tue, Apr 15, 2008 at 9:51 AM, Ruwan Linton <ru...@gmail.com>
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 <wa...@gmail.com>
> 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"
>
Re: Composite Services Architectural question
Posted by Wayne Keenan <wa...@gmail.com>.
Thanks for your very generous offer, but I think longer term BPEL is much
more suited to our requirements, and I wouldn't want to waste
your time to satisfy my curiosity.
All the best
Wayne
On Thu, Apr 17, 2008 at 9:58 AM, Ruwan Linton <ru...@gmail.com>
wrote:
> Hi Wayne,
>
> We have done similar stuff using Synapse. So if you could send me a sample
> request and the exact requirement including any other schemas of the
> requests that has to be generated by synapse, (may be with sample services
> or WSDL) I would be happy to give you the exact configuration for you to
> use
> for the scenario. You may send the requests to me privately if you feel
> uncomfortable in sharing these in public. My email address is ruwan AT
> wso2
> DOT com.
>
> Thanks,
> Ruwan
>
> On Thu, Apr 17, 2008 at 1:25 PM, Wayne Keenan <wa...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Thanks for all your help, but the amount of configuration involved todo
> > this
> > is perhaps indicating my requirements are not a best fit for Synapse's
> > intended use, no offence to Synapse.
> > We have decided to find another mecanism to co-ordinate the service
> > invocations, and I'm currently looking at Apache ODE.
> > That is not to say we won't be using Synapse, quite the opposite, we
> will
> > still be Synapse on the 'front line', todo: routing, failover, load
> > balancing etc.
> >
> > Regards
> > Wayne
> >
> >
> > On Wed, Apr 16, 2008 at 3:42 PM, Ruwan Linton <ru...@gmail.com>
> > wrote:
> >
> > > Hi Wayne,
> > >
> > > I was thinking you are using the message mediation but not a proxy. In
> > > your
> > > case the out sequence of the proxy will not be called because the
> > message
> > > does not go out on the normal path. So here is the workaround for
> that.
> > >
> > > You will need to put a dummy outSequence for the proxy because that is
> > > required, but you need to append the ossj_fault_out to the end of the
> > > proxy
> > > in sequence execution. Since there is a clone mediator these linkages
> > > should
> > > happen at the two cloned targets. In effect you should modify the
> > > ossj_fault_main and ossj_fault_comment_wrapper sequences and add the
> > > following configuration point to the end of these sequences.
> > >
> > > <sequence key="ossj_fault_out"/>
> > >
> > > Modify the config as I proposed and let me know the results. I will
> > guide
> > > you for any other changes to get this done if you get any more issues
> on
> > > this.
> > >
> > > Thanks,
> > > Ruwan
> > >
> > > On Wed, Apr 16, 2008 at 7:33 PM, Wayne Keenan <wa...@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Help, I am being quite thick and was wonodering if someone could
> > sanity
> > > > check my config please, liberlay doused with printf debugging.
> > > > My backend service (a RESTful POX service that accept the SOAP
> payload
> > > as
> > > > the 'callout' doesn't support POX) is called and a responds, but the
> > > > processing stops at : DEBUG SequenceMediator End : Sequence
> > > > <ossj_fault_main>
> > > >
> > > > The out sequence 'ossj_fault_out' is never called and I am at a loss
> > as
> > > to
> > > > why. (The namings are an unfortunate clash, but its a
> FaultReporting
> > > > interface)
> > > >
> > > > My config is below:
> > > >
> > > > <definitions xmlns="http://ws.apache.org/ns/synapse">
> > > >
> > > >
> > > > <!-- the SimpleURLRegistry allows access to a URL based registry
> > > (e.g.
> > > > file:/// or http://) -->
> > > > <registry
> > > > provider="org.apache.synapse.registry.url.SimpleURLRegistry">
> > > > <parameter name="root">
> > > >
> > > >
> > > >
> > >
> >
> file:../../workspace/OS3_SOA_POC/src/test/config/Synapse/repository/conf/os3/resources/
> > > > </parameter>
> > > > <!-- the root property of the simple URL registry helps
> resolve
> > a
> > > > resource URL as root + key -->
> > > > <parameter name="cachableDuration">1000</parameter><!-- all
> > > > resources loaded from the URL registry would be cached for this
> number
> > > of
> > > > milli seconds -->
> > > > </registry>
> > > >
> > > > <!-- Entry point -->
> > > > <proxy name="JVTAlarmCreationSession" transports="https">
> > > > <publishWSDL
> > > >
> > > > key="OSSJ/wsdl/FaultManagement/v1-0/JVTAlarmCreationSession.wsdl" />
> > > > <target inSequence="ossj_fault_in"
> outSequence="ossj_fault_out"
> > > />
> > > > </proxy>
> > > >
> > > > <!-- handle incoming messages -->
> > > > <sequence name="ossj_fault_in" trace="enable">
> > > > <log level="full">
> > > > <property name="SECTION" value="inSequence" />
> > > > </log>
> > > > <clone>
> > > > <target sequence="ossj_fault_main" />
> > > > <target sequence="ossj_fault_comments_wrapper" />
> > > > </clone>
> > > > </sequence>
> > > >
> > > > <!-- send response messages to client -->
> > > > <sequence name="ossj_fault_out" trace="enable">
> > > > <log level="full">
> > > > <property name="SECTION" value="ossj_fault_out" />
> > > > </log>
> > > > <xslt key="OSSJ/transform/AddWrapperTag.xslt" />
> > > > <aggregate>
> > > > <correlateOn expression="//wrapper" />
> > > > <onComplete>
> > > > <iterate preservePayload="true"
> > > >
> > > >
> > > >
> > >
> >
> expression="/wrapper/*[local-name()='createAlarmByValueRequest']/*[local-name()='alarmValue']/*[local-name()='comments']/*[local-name()='item']">
> > > > <log level="full">
> > > > <property name="SECTION" value="iterate" />
> > > > </log>
> > > > <target sequence="final" />
> > > > </iterate>
> > > > </onComplete>
> > > > </aggregate>
> > > > </sequence>
> > > >
> > > >
> > > > <sequence name="ossj_fault_main" trace="enable">
> > > > <log level="full">
> > > > <property name="SECTION"
> > > > value="ossj_faults_main_precallout_prexslt" />
> > > > </log>
> > > >
> > > > <xslt
> > > >
> > > >
> > > >
> > >
> >
> key="OSSJ/transform/FaultManagement/v1-0/createAlarmByValueRequest_Main.xslt"
> > > > />
> > > > <log level="full">
> > > > <property name="SECTION"
> > > > value="ossj_faults_main_precallout_postxslt" />
> > > > </log>
> > > > <callout serviceURL="http://localhost:8764/ars/create/">
> > > > <source
> > > > xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
> > > > xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> > > > xpath="s11:Body/child::*[fn:position()=1] |
> > > > s12:Body/child::*[fn:position()=1]" />
> > > > <target
> > > > xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
> > > > xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> > > > xpath="s11:Body/child::*[fn:position()=1] |
> > > > s12:Body/child::*[fn:position()=1]" />
> > > > </callout>
> > > > <log level="full">
> > > > <property name="SECTION"
> > > > value="ossj_faults_main_post_callout" />
> > > > </log>
> > > > <property name="RESPONSE" value="true" scope="axis2" />
> > > > </sequence>
> > > >
> > > > <sequence name="ossj_fault_comments_wrapper" trace="enable">
> > > > <log level="full">
> > > > <property name="SECTION"
> > > > value="ossj_fault_comments_wrapper" />
> > > > </log>
> > > >
> > > > <property name="RESPONSE" value="true" scope="axis2" />
> > > > <send/>
> > > > </sequence>
> > > >
> > > > <sequence name="final" trace="enable">
> > > > <log level="full">
> > > > <property name="SECTION" value="final" />
> > > > </log>
> > > > <!-- xslt -->
> > > > <send />
> > > > </sequence>
> > > >
> > > > </definitions>
> > > >
> > > >
> > > > On Wed, Apr 16, 2008 at 11:06 AM, Wayne Keenan <
> wayne.keenan@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > 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 <
> > ruwan.linton@gmail.com>
> > > > > 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 <
> > > wayne.keenan@gmail.com
> > > > >
> > > > > > 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 <
> > > > ruwan.linton@gmail.com>
> > > > > > > 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 <
> > > > > > wayne.keenan@gmail.com>
> > > > > > > > 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"
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Ruwan Linton
> > > http://www.wso2.org - "Oxygenating the Web Services Platform"
> > >
> >
>
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
Re: Composite Services Architectural question
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Wayne,
We have done similar stuff using Synapse. So if you could send me a sample
request and the exact requirement including any other schemas of the
requests that has to be generated by synapse, (may be with sample services
or WSDL) I would be happy to give you the exact configuration for you to use
for the scenario. You may send the requests to me privately if you feel
uncomfortable in sharing these in public. My email address is ruwan AT wso2
DOT com.
Thanks,
Ruwan
On Thu, Apr 17, 2008 at 1:25 PM, Wayne Keenan <wa...@gmail.com>
wrote:
> Hi,
>
> Thanks for all your help, but the amount of configuration involved todo
> this
> is perhaps indicating my requirements are not a best fit for Synapse's
> intended use, no offence to Synapse.
> We have decided to find another mecanism to co-ordinate the service
> invocations, and I'm currently looking at Apache ODE.
> That is not to say we won't be using Synapse, quite the opposite, we will
> still be Synapse on the 'front line', todo: routing, failover, load
> balancing etc.
>
> Regards
> Wayne
>
>
> On Wed, Apr 16, 2008 at 3:42 PM, Ruwan Linton <ru...@gmail.com>
> wrote:
>
> > Hi Wayne,
> >
> > I was thinking you are using the message mediation but not a proxy. In
> > your
> > case the out sequence of the proxy will not be called because the
> message
> > does not go out on the normal path. So here is the workaround for that.
> >
> > You will need to put a dummy outSequence for the proxy because that is
> > required, but you need to append the ossj_fault_out to the end of the
> > proxy
> > in sequence execution. Since there is a clone mediator these linkages
> > should
> > happen at the two cloned targets. In effect you should modify the
> > ossj_fault_main and ossj_fault_comment_wrapper sequences and add the
> > following configuration point to the end of these sequences.
> >
> > <sequence key="ossj_fault_out"/>
> >
> > Modify the config as I proposed and let me know the results. I will
> guide
> > you for any other changes to get this done if you get any more issues on
> > this.
> >
> > Thanks,
> > Ruwan
> >
> > On Wed, Apr 16, 2008 at 7:33 PM, Wayne Keenan <wa...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Help, I am being quite thick and was wonodering if someone could
> sanity
> > > check my config please, liberlay doused with printf debugging.
> > > My backend service (a RESTful POX service that accept the SOAP payload
> > as
> > > the 'callout' doesn't support POX) is called and a responds, but the
> > > processing stops at : DEBUG SequenceMediator End : Sequence
> > > <ossj_fault_main>
> > >
> > > The out sequence 'ossj_fault_out' is never called and I am at a loss
> as
> > to
> > > why. (The namings are an unfortunate clash, but its a FaultReporting
> > > interface)
> > >
> > > My config is below:
> > >
> > > <definitions xmlns="http://ws.apache.org/ns/synapse">
> > >
> > >
> > > <!-- the SimpleURLRegistry allows access to a URL based registry
> > (e.g.
> > > file:/// or http://) -->
> > > <registry
> > > provider="org.apache.synapse.registry.url.SimpleURLRegistry">
> > > <parameter name="root">
> > >
> > >
> > >
> >
> file:../../workspace/OS3_SOA_POC/src/test/config/Synapse/repository/conf/os3/resources/
> > > </parameter>
> > > <!-- the root property of the simple URL registry helps resolve
> a
> > > resource URL as root + key -->
> > > <parameter name="cachableDuration">1000</parameter><!-- all
> > > resources loaded from the URL registry would be cached for this number
> > of
> > > milli seconds -->
> > > </registry>
> > >
> > > <!-- Entry point -->
> > > <proxy name="JVTAlarmCreationSession" transports="https">
> > > <publishWSDL
> > >
> > > key="OSSJ/wsdl/FaultManagement/v1-0/JVTAlarmCreationSession.wsdl" />
> > > <target inSequence="ossj_fault_in" outSequence="ossj_fault_out"
> > />
> > > </proxy>
> > >
> > > <!-- handle incoming messages -->
> > > <sequence name="ossj_fault_in" trace="enable">
> > > <log level="full">
> > > <property name="SECTION" value="inSequence" />
> > > </log>
> > > <clone>
> > > <target sequence="ossj_fault_main" />
> > > <target sequence="ossj_fault_comments_wrapper" />
> > > </clone>
> > > </sequence>
> > >
> > > <!-- send response messages to client -->
> > > <sequence name="ossj_fault_out" trace="enable">
> > > <log level="full">
> > > <property name="SECTION" value="ossj_fault_out" />
> > > </log>
> > > <xslt key="OSSJ/transform/AddWrapperTag.xslt" />
> > > <aggregate>
> > > <correlateOn expression="//wrapper" />
> > > <onComplete>
> > > <iterate preservePayload="true"
> > >
> > >
> > >
> >
> expression="/wrapper/*[local-name()='createAlarmByValueRequest']/*[local-name()='alarmValue']/*[local-name()='comments']/*[local-name()='item']">
> > > <log level="full">
> > > <property name="SECTION" value="iterate" />
> > > </log>
> > > <target sequence="final" />
> > > </iterate>
> > > </onComplete>
> > > </aggregate>
> > > </sequence>
> > >
> > >
> > > <sequence name="ossj_fault_main" trace="enable">
> > > <log level="full">
> > > <property name="SECTION"
> > > value="ossj_faults_main_precallout_prexslt" />
> > > </log>
> > >
> > > <xslt
> > >
> > >
> > >
> >
> key="OSSJ/transform/FaultManagement/v1-0/createAlarmByValueRequest_Main.xslt"
> > > />
> > > <log level="full">
> > > <property name="SECTION"
> > > value="ossj_faults_main_precallout_postxslt" />
> > > </log>
> > > <callout serviceURL="http://localhost:8764/ars/create/">
> > > <source
> > > xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
> > > xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> > > xpath="s11:Body/child::*[fn:position()=1] |
> > > s12:Body/child::*[fn:position()=1]" />
> > > <target
> > > xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
> > > xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> > > xpath="s11:Body/child::*[fn:position()=1] |
> > > s12:Body/child::*[fn:position()=1]" />
> > > </callout>
> > > <log level="full">
> > > <property name="SECTION"
> > > value="ossj_faults_main_post_callout" />
> > > </log>
> > > <property name="RESPONSE" value="true" scope="axis2" />
> > > </sequence>
> > >
> > > <sequence name="ossj_fault_comments_wrapper" trace="enable">
> > > <log level="full">
> > > <property name="SECTION"
> > > value="ossj_fault_comments_wrapper" />
> > > </log>
> > >
> > > <property name="RESPONSE" value="true" scope="axis2" />
> > > <send/>
> > > </sequence>
> > >
> > > <sequence name="final" trace="enable">
> > > <log level="full">
> > > <property name="SECTION" value="final" />
> > > </log>
> > > <!-- xslt -->
> > > <send />
> > > </sequence>
> > >
> > > </definitions>
> > >
> > >
> > > On Wed, Apr 16, 2008 at 11:06 AM, Wayne Keenan <wayne.keenan@gmail.com
> >
> > > wrote:
> > >
> > > > 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 <
> ruwan.linton@gmail.com>
> > > > 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 <
> > wayne.keenan@gmail.com
> > > >
> > > > > 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 <
> > > ruwan.linton@gmail.com>
> > > > > > 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 <
> > > > > wayne.keenan@gmail.com>
> > > > > > > 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"
> > > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Ruwan Linton
> > http://www.wso2.org - "Oxygenating the Web Services Platform"
> >
>
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
Re: Composite Services Architectural question
Posted by Wayne Keenan <wa...@gmail.com>.
Hi,
Thanks for all your help, but the amount of configuration involved todo this
is perhaps indicating my requirements are not a best fit for Synapse's
intended use, no offence to Synapse.
We have decided to find another mecanism to co-ordinate the service
invocations, and I'm currently looking at Apache ODE.
That is not to say we won't be using Synapse, quite the opposite, we will
still be Synapse on the 'front line', todo: routing, failover, load
balancing etc.
Regards
Wayne
On Wed, Apr 16, 2008 at 3:42 PM, Ruwan Linton <ru...@gmail.com>
wrote:
> Hi Wayne,
>
> I was thinking you are using the message mediation but not a proxy. In
> your
> case the out sequence of the proxy will not be called because the message
> does not go out on the normal path. So here is the workaround for that.
>
> You will need to put a dummy outSequence for the proxy because that is
> required, but you need to append the ossj_fault_out to the end of the
> proxy
> in sequence execution. Since there is a clone mediator these linkages
> should
> happen at the two cloned targets. In effect you should modify the
> ossj_fault_main and ossj_fault_comment_wrapper sequences and add the
> following configuration point to the end of these sequences.
>
> <sequence key="ossj_fault_out"/>
>
> Modify the config as I proposed and let me know the results. I will guide
> you for any other changes to get this done if you get any more issues on
> this.
>
> Thanks,
> Ruwan
>
> On Wed, Apr 16, 2008 at 7:33 PM, Wayne Keenan <wa...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Help, I am being quite thick and was wonodering if someone could sanity
> > check my config please, liberlay doused with printf debugging.
> > My backend service (a RESTful POX service that accept the SOAP payload
> as
> > the 'callout' doesn't support POX) is called and a responds, but the
> > processing stops at : DEBUG SequenceMediator End : Sequence
> > <ossj_fault_main>
> >
> > The out sequence 'ossj_fault_out' is never called and I am at a loss as
> to
> > why. (The namings are an unfortunate clash, but its a FaultReporting
> > interface)
> >
> > My config is below:
> >
> > <definitions xmlns="http://ws.apache.org/ns/synapse">
> >
> >
> > <!-- the SimpleURLRegistry allows access to a URL based registry
> (e.g.
> > file:/// or http://) -->
> > <registry
> > provider="org.apache.synapse.registry.url.SimpleURLRegistry">
> > <parameter name="root">
> >
> >
> >
> file:../../workspace/OS3_SOA_POC/src/test/config/Synapse/repository/conf/os3/resources/
> > </parameter>
> > <!-- the root property of the simple URL registry helps resolve a
> > resource URL as root + key -->
> > <parameter name="cachableDuration">1000</parameter><!-- all
> > resources loaded from the URL registry would be cached for this number
> of
> > milli seconds -->
> > </registry>
> >
> > <!-- Entry point -->
> > <proxy name="JVTAlarmCreationSession" transports="https">
> > <publishWSDL
> >
> > key="OSSJ/wsdl/FaultManagement/v1-0/JVTAlarmCreationSession.wsdl" />
> > <target inSequence="ossj_fault_in" outSequence="ossj_fault_out"
> />
> > </proxy>
> >
> > <!-- handle incoming messages -->
> > <sequence name="ossj_fault_in" trace="enable">
> > <log level="full">
> > <property name="SECTION" value="inSequence" />
> > </log>
> > <clone>
> > <target sequence="ossj_fault_main" />
> > <target sequence="ossj_fault_comments_wrapper" />
> > </clone>
> > </sequence>
> >
> > <!-- send response messages to client -->
> > <sequence name="ossj_fault_out" trace="enable">
> > <log level="full">
> > <property name="SECTION" value="ossj_fault_out" />
> > </log>
> > <xslt key="OSSJ/transform/AddWrapperTag.xslt" />
> > <aggregate>
> > <correlateOn expression="//wrapper" />
> > <onComplete>
> > <iterate preservePayload="true"
> >
> >
> >
> expression="/wrapper/*[local-name()='createAlarmByValueRequest']/*[local-name()='alarmValue']/*[local-name()='comments']/*[local-name()='item']">
> > <log level="full">
> > <property name="SECTION" value="iterate" />
> > </log>
> > <target sequence="final" />
> > </iterate>
> > </onComplete>
> > </aggregate>
> > </sequence>
> >
> >
> > <sequence name="ossj_fault_main" trace="enable">
> > <log level="full">
> > <property name="SECTION"
> > value="ossj_faults_main_precallout_prexslt" />
> > </log>
> >
> > <xslt
> >
> >
> >
> key="OSSJ/transform/FaultManagement/v1-0/createAlarmByValueRequest_Main.xslt"
> > />
> > <log level="full">
> > <property name="SECTION"
> > value="ossj_faults_main_precallout_postxslt" />
> > </log>
> > <callout serviceURL="http://localhost:8764/ars/create/">
> > <source
> > xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
> > xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> > xpath="s11:Body/child::*[fn:position()=1] |
> > s12:Body/child::*[fn:position()=1]" />
> > <target
> > xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
> > xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> > xpath="s11:Body/child::*[fn:position()=1] |
> > s12:Body/child::*[fn:position()=1]" />
> > </callout>
> > <log level="full">
> > <property name="SECTION"
> > value="ossj_faults_main_post_callout" />
> > </log>
> > <property name="RESPONSE" value="true" scope="axis2" />
> > </sequence>
> >
> > <sequence name="ossj_fault_comments_wrapper" trace="enable">
> > <log level="full">
> > <property name="SECTION"
> > value="ossj_fault_comments_wrapper" />
> > </log>
> >
> > <property name="RESPONSE" value="true" scope="axis2" />
> > <send/>
> > </sequence>
> >
> > <sequence name="final" trace="enable">
> > <log level="full">
> > <property name="SECTION" value="final" />
> > </log>
> > <!-- xslt -->
> > <send />
> > </sequence>
> >
> > </definitions>
> >
> >
> > On Wed, Apr 16, 2008 at 11:06 AM, Wayne Keenan <wa...@gmail.com>
> > wrote:
> >
> > > 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 <ru...@gmail.com>
> > > 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 <
> wayne.keenan@gmail.com
> > >
> > > > 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 <
> > ruwan.linton@gmail.com>
> > > > > 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 <
> > > > wayne.keenan@gmail.com>
> > > > > > 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"
> > > >
> > >
> > >
> >
>
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
Re: Composite Services Architectural question
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Wayne,
I was thinking you are using the message mediation but not a proxy. In your
case the out sequence of the proxy will not be called because the message
does not go out on the normal path. So here is the workaround for that.
You will need to put a dummy outSequence for the proxy because that is
required, but you need to append the ossj_fault_out to the end of the proxy
in sequence execution. Since there is a clone mediator these linkages should
happen at the two cloned targets. In effect you should modify the
ossj_fault_main and ossj_fault_comment_wrapper sequences and add the
following configuration point to the end of these sequences.
<sequence key="ossj_fault_out"/>
Modify the config as I proposed and let me know the results. I will guide
you for any other changes to get this done if you get any more issues on
this.
Thanks,
Ruwan
On Wed, Apr 16, 2008 at 7:33 PM, Wayne Keenan <wa...@gmail.com>
wrote:
> Hi,
>
> Help, I am being quite thick and was wonodering if someone could sanity
> check my config please, liberlay doused with printf debugging.
> My backend service (a RESTful POX service that accept the SOAP payload as
> the 'callout' doesn't support POX) is called and a responds, but the
> processing stops at : DEBUG SequenceMediator End : Sequence
> <ossj_fault_main>
>
> The out sequence 'ossj_fault_out' is never called and I am at a loss as to
> why. (The namings are an unfortunate clash, but its a FaultReporting
> interface)
>
> My config is below:
>
> <definitions xmlns="http://ws.apache.org/ns/synapse">
>
>
> <!-- the SimpleURLRegistry allows access to a URL based registry (e.g.
> file:/// or http://) -->
> <registry
> provider="org.apache.synapse.registry.url.SimpleURLRegistry">
> <parameter name="root">
>
>
> file:../../workspace/OS3_SOA_POC/src/test/config/Synapse/repository/conf/os3/resources/
> </parameter>
> <!-- the root property of the simple URL registry helps resolve a
> resource URL as root + key -->
> <parameter name="cachableDuration">1000</parameter><!-- all
> resources loaded from the URL registry would be cached for this number of
> milli seconds -->
> </registry>
>
> <!-- Entry point -->
> <proxy name="JVTAlarmCreationSession" transports="https">
> <publishWSDL
>
> key="OSSJ/wsdl/FaultManagement/v1-0/JVTAlarmCreationSession.wsdl" />
> <target inSequence="ossj_fault_in" outSequence="ossj_fault_out" />
> </proxy>
>
> <!-- handle incoming messages -->
> <sequence name="ossj_fault_in" trace="enable">
> <log level="full">
> <property name="SECTION" value="inSequence" />
> </log>
> <clone>
> <target sequence="ossj_fault_main" />
> <target sequence="ossj_fault_comments_wrapper" />
> </clone>
> </sequence>
>
> <!-- send response messages to client -->
> <sequence name="ossj_fault_out" trace="enable">
> <log level="full">
> <property name="SECTION" value="ossj_fault_out" />
> </log>
> <xslt key="OSSJ/transform/AddWrapperTag.xslt" />
> <aggregate>
> <correlateOn expression="//wrapper" />
> <onComplete>
> <iterate preservePayload="true"
>
>
> expression="/wrapper/*[local-name()='createAlarmByValueRequest']/*[local-name()='alarmValue']/*[local-name()='comments']/*[local-name()='item']">
> <log level="full">
> <property name="SECTION" value="iterate" />
> </log>
> <target sequence="final" />
> </iterate>
> </onComplete>
> </aggregate>
> </sequence>
>
>
> <sequence name="ossj_fault_main" trace="enable">
> <log level="full">
> <property name="SECTION"
> value="ossj_faults_main_precallout_prexslt" />
> </log>
>
> <xslt
>
>
> key="OSSJ/transform/FaultManagement/v1-0/createAlarmByValueRequest_Main.xslt"
> />
> <log level="full">
> <property name="SECTION"
> value="ossj_faults_main_precallout_postxslt" />
> </log>
> <callout serviceURL="http://localhost:8764/ars/create/">
> <source
> xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> xpath="s11:Body/child::*[fn:position()=1] |
> s12:Body/child::*[fn:position()=1]" />
> <target
> xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
> xpath="s11:Body/child::*[fn:position()=1] |
> s12:Body/child::*[fn:position()=1]" />
> </callout>
> <log level="full">
> <property name="SECTION"
> value="ossj_faults_main_post_callout" />
> </log>
> <property name="RESPONSE" value="true" scope="axis2" />
> </sequence>
>
> <sequence name="ossj_fault_comments_wrapper" trace="enable">
> <log level="full">
> <property name="SECTION"
> value="ossj_fault_comments_wrapper" />
> </log>
>
> <property name="RESPONSE" value="true" scope="axis2" />
> <send/>
> </sequence>
>
> <sequence name="final" trace="enable">
> <log level="full">
> <property name="SECTION" value="final" />
> </log>
> <!-- xslt -->
> <send />
> </sequence>
>
> </definitions>
>
>
> On Wed, Apr 16, 2008 at 11:06 AM, Wayne Keenan <wa...@gmail.com>
> wrote:
>
> > 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 <ru...@gmail.com>
> > 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 <wayne.keenan@gmail.com
> >
> > > 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 <
> ruwan.linton@gmail.com>
> > > > 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 <
> > > wayne.keenan@gmail.com>
> > > > > 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"
> > >
> >
> >
>
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
Re: Composite Services Architectural question
Posted by Wayne Keenan <wa...@gmail.com>.
Hi,
Help, I am being quite thick and was wonodering if someone could sanity
check my config please, liberlay doused with printf debugging.
My backend service (a RESTful POX service that accept the SOAP payload as
the 'callout' doesn't support POX) is called and a responds, but the
processing stops at : DEBUG SequenceMediator End : Sequence
<ossj_fault_main>
The out sequence 'ossj_fault_out' is never called and I am at a loss as to
why. (The namings are an unfortunate clash, but its a FaultReporting
interface)
My config is below:
<definitions xmlns="http://ws.apache.org/ns/synapse">
<!-- the SimpleURLRegistry allows access to a URL based registry (e.g.
file:/// or http://) -->
<registry
provider="org.apache.synapse.registry.url.SimpleURLRegistry">
<parameter name="root">
file:../../workspace/OS3_SOA_POC/src/test/config/Synapse/repository/conf/os3/resources/
</parameter>
<!-- the root property of the simple URL registry helps resolve a
resource URL as root + key -->
<parameter name="cachableDuration">1000</parameter><!-- all
resources loaded from the URL registry would be cached for this number of
milli seconds -->
</registry>
<!-- Entry point -->
<proxy name="JVTAlarmCreationSession" transports="https">
<publishWSDL
key="OSSJ/wsdl/FaultManagement/v1-0/JVTAlarmCreationSession.wsdl" />
<target inSequence="ossj_fault_in" outSequence="ossj_fault_out" />
</proxy>
<!-- handle incoming messages -->
<sequence name="ossj_fault_in" trace="enable">
<log level="full">
<property name="SECTION" value="inSequence" />
</log>
<clone>
<target sequence="ossj_fault_main" />
<target sequence="ossj_fault_comments_wrapper" />
</clone>
</sequence>
<!-- send response messages to client -->
<sequence name="ossj_fault_out" trace="enable">
<log level="full">
<property name="SECTION" value="ossj_fault_out" />
</log>
<xslt key="OSSJ/transform/AddWrapperTag.xslt" />
<aggregate>
<correlateOn expression="//wrapper" />
<onComplete>
<iterate preservePayload="true"
expression="/wrapper/*[local-name()='createAlarmByValueRequest']/*[local-name()='alarmValue']/*[local-name()='comments']/*[local-name()='item']">
<log level="full">
<property name="SECTION" value="iterate" />
</log>
<target sequence="final" />
</iterate>
</onComplete>
</aggregate>
</sequence>
<sequence name="ossj_fault_main" trace="enable">
<log level="full">
<property name="SECTION"
value="ossj_faults_main_precallout_prexslt" />
</log>
<xslt
key="OSSJ/transform/FaultManagement/v1-0/createAlarmByValueRequest_Main.xslt"
/>
<log level="full">
<property name="SECTION"
value="ossj_faults_main_precallout_postxslt" />
</log>
<callout serviceURL="http://localhost:8764/ars/create/">
<source
xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xpath="s11:Body/child::*[fn:position()=1] |
s12:Body/child::*[fn:position()=1]" />
<target
xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xpath="s11:Body/child::*[fn:position()=1] |
s12:Body/child::*[fn:position()=1]" />
</callout>
<log level="full">
<property name="SECTION"
value="ossj_faults_main_post_callout" />
</log>
<property name="RESPONSE" value="true" scope="axis2" />
</sequence>
<sequence name="ossj_fault_comments_wrapper" trace="enable">
<log level="full">
<property name="SECTION"
value="ossj_fault_comments_wrapper" />
</log>
<property name="RESPONSE" value="true" scope="axis2" />
<send/>
</sequence>
<sequence name="final" trace="enable">
<log level="full">
<property name="SECTION" value="final" />
</log>
<!-- xslt -->
<send />
</sequence>
</definitions>
On Wed, Apr 16, 2008 at 11:06 AM, Wayne Keenan <wa...@gmail.com>
wrote:
> 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 <ru...@gmail.com>
> 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 <wa...@gmail.com>
> > 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 <ru...@gmail.com>
> > > 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 <
> > wayne.keenan@gmail.com>
> > > > 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"
> >
>
>
Re: Composite Services Architectural question
Posted by Wayne Keenan <wa...@gmail.com>.
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 <ru...@gmail.com>
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 <wa...@gmail.com>
> 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 <ru...@gmail.com>
> > 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 <wa...@gmail.com>
> > > 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"
>
Re: Composite Services Architectural question
Posted by Ruwan Linton <ru...@gmail.com>.
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 <wa...@gmail.com>
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 <ru...@gmail.com>
> 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 <wa...@gmail.com>
> > 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"
Re: Composite Services Architectural question
Posted by Wayne Keenan <wa...@gmail.com>.
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 <ru...@gmail.com>
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 <wa...@gmail.com>
> 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"
>
Re: Composite Services Architectural question
Posted by Ruwan Linton <ru...@gmail.com>.
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 <wa...@gmail.com>
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"