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