Hi Tammo, Thanks for the reply.
At BpelRuntimeContext.invoke, it was setting the ASYNC status despite the status is FAILURE in case of one way request. Now, I am not setting the ASYNC status at all. I changed it to RESPONSE if there is no FAILURE status so that InvokeResponseChannel onResponse is hit for the default successful one way request and onFailure will be hit for the FAILURE scenario. I am concerned whether this has any impact on the other functionality. I tested with a sample process and it worked fine. Regards Nandika On Tue, Sep 17, 2013 at 5:12 AM, Tammo van Lessen <tvanles...@gmail.com>wrote: > Hi Nandika, > > in general it looks good IMO, but I have the same concern about the changed > mex status. My educated guess is that it is fine, > https://issues.apache.org/jira/browse/ODE-54 says that the ONE_WAY mex has > been dropped in favor of ASYNC + REQUEST_ONLY, based on that I would follow > that a failed ONE_WAY would then be FAILURE + REQUEST_ONLY, which is > exactly what you did, isn't it? > > Cheers, > Tammo > > > On Mon, Sep 16, 2013 at 12:27 PM, Nandika Jayawardana <jayaw...@gmail.com > >wrote: > > > I modified the following code sections of ode to make it work. > > > > For the one way invoke, when the service endpoint is down, then axis2 > will > > show the error message, > > "INFO {org.apache.axis2.transport.http.HTTPSender} - Unable to > sendViaPost > > to url". > > This exception is captured captured and sent to ode and is available at > > mex. > > > > At BpelRuntimeContextImpl.invoke method there is a comparison to check > the > > message exchange pattern and i changed that code as follows. > > > > Before change : > > if > > > > > (mexDao.getPattern().equals(MessageExchangePattern.REQUEST_ONLY.toString())) > > { > > mexDao.setStatus(MessageExchange.Status.ASYNC.toString()); > > > > After change: > > if > > > > > (mexDao.getPattern().equals(MessageExchangePattern.REQUEST_ONLY.toString())) > > { > > if(mex.getStatus() != MessageExchange.Status.FAILURE) > > > > mexDao.setStatus(MessageExchange.Status.RESPONSE.toString()); > > > > and Then I added an InvokeResponseChannel at one way invoke handling > logic > > as follows to INVOKE class. > > > > if (!isTwoWay) { > > FaultData faultData = null; > > InvokeResponseChannel invokeResponseChannel = > > newChannel(InvokeResponseChannel.class); > > > > final String mexId = > > getBpelRuntimeContext().invoke(_oinvoke.getId(), > > _scopeFrame.resolve(_oinvoke.partnerLink), > > _oinvoke.operation, outboundMsg, > > invokeResponseChannel); > > > > > > object(false, new > > InvokeResponseChannelListener(invokeResponseChannel) { > > public void onResponse() { > > _self.parent.completed(null, > > CompensationHandler.emptySet()); > > } > > > > public void onFault() { > > > > } > > > > public void onFailure() { > > String reason = > > getBpelRuntimeContext().getPartnerFaultExplanation(mexId); > > __log.error("Failure during invoke: " + > > reason); > > try { > > Element el = > > > > > DOMUtils.stringToDOM("<invokeFailure><![CDATA["+reason+"]]></invokeFailure>"); > > _self.parent.failure(reason, el); > > } catch (Exception e) { > > _self.parent.failure(reason, null); > > } > > > > } > > }); > > } > > > > I tested this logic and its propagating the one way invocation failure to > > bpel process correctly. Is this the correct way to solve this problem. Is > > there any impact in changing the mex status to RESPONSE from ASYNC. > > > > Regards > > Nandika > > > > > > On Tue, Jul 16, 2013 at 11:24 PM, Sathwik B P <sathwik...@gmail.com> > > wrote: > > > > > Keheliya, > > > > > > Would you be able to attach the error logs. > > > What's the behavior with a sync call? > > > > > > regards, > > > sathwik > > > > > > On Wed, Jul 10, 2013 at 9:45 PM, Tammo van Lessen < > tvanles...@gmail.com > > > >wrote: > > > > > > > Hi Keheliya, > > > > > > > > there is no workaround yet, it is probably a bit tricky as you will > > need > > > to > > > > use an InvokeResponseChannel like in the two-way case but use it only > > for > > > > ACKing that the invoke was successful or NACKing if it was not. > Should > > > not > > > > be too hard though. > > > > > > > > HTH, > > > > Tammo > > > > > > > > > > > > On Tue, Jul 9, 2013 at 2:17 PM, Keheliya Gallaba < > > > > keheliya.gall...@gmail.com > > > > > wrote: > > > > > > > > > Hi Tammo, > > > > > > > > > > Yes. That looks like the same issue. Is there any other work around > > to > > > > find > > > > > out in the BPEL process when an one-way invoke fails due to a > > transport > > > > > error? > > > > > > > > > > Thanks, > > > > > Keheliya > > > > > > > > > > On 9 July 2013 17:27, Tammo van Lessen <tvanles...@gmail.com> > wrote: > > > > > > > > > > > Hi Keheliya, > > > > > > > > > > > > If I understand you correctly, this is sort of a known issue. > Could > > > you > > > > > > verify that its related to > > > > https://issues.apache.org/jira/browse/ODE-714 > > > > > ? > > > > > > > > > > > > Thanks, > > > > > > Tammo > > > > > > > > > > > > > > > > > > On Tue, Jul 9, 2013 at 12:15 PM, Keheliya Gallaba < > > > > > > keheliya.gall...@gmail.com> wrote: > > > > > > > > > > > > > Hi devs, > > > > > > > > > > > > > > In ODE, when an invoke of the BPEL has an one-way call, if the > > > > endpoint > > > > > > is > > > > > > > not reachable, it just prints the 'Unable to sendViaPost' error > > in > > > > the > > > > > > > console and continues to execute the rest of the process > without > > > > > raising > > > > > > a > > > > > > > fault or halting it. As described here[1] we can set > > > 'faultOnFailure' > > > > > to > > > > > > > true. But it gets activated only when a TimeOut occurs or a > Fault > > > > comes > > > > > > in > > > > > > > the response of a two-way message (so doesn't apply to the > > one-way > > > > > > invoke) > > > > > > > Am I missing something here? The requirement is to raise a > fault > > > and > > > > > halt > > > > > > > the process flow when the back end service is unavailable or > > > network > > > > > > > failure in an one-way call. Is there any other way to achieve > > this? > > > > > > > > > > > > > > Thanks, > > > > > > > Keheliya > > > > > > > > > > > > > > [1] > > > > > > http://ode.apache.org/extensions/activity-failure-and-recovery.html > > > > > > > > > > > > > > -- > > > > > > > Keheliya Gallaba > > > > > > > More about me: http://about.me/keheliya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Tammo van Lessen - http://www.taval.de > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Keheliya Gallaba > > > > > More about me: http://about.me/keheliya > > > > > > > > > > > > > > > > > > > > > -- > > > > Tammo van Lessen - http://www.taval.de > > > > > > > > > > > > > -- > Tammo van Lessen - http://www.taval.de >
