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

Reply via email to