Hello Antonie, Terry, all I was digging the sources of ODE and found following method:
org.apache.ode.bpel.engine.BpelEngineImpl#route(QName, Message) Which returns the process that could be used for P2P communication was changed from using Entpoints to using Service QNames by Antonie committed to revision 830367 (I'm talking here about ODE_1X trunk) with following comments: -Introduced new property "p2p.mex.timeout" used as default value for process-to-process mex timeout -Changed _serviceMap type to Map<QName, List<BpelProcess>> to optimize routing common case -MEX timeout no longer multipled by 1.5 for invokeCheck My idea was instead of commenting the routing completely was to enable internal P2P shortcut only when ODE is quite sure a recipient process will be able to handle this message. In ideal case that would be checking wherever process implement that particular operation of that particular port-type. However for my use-cases it would be enough just to check wherever port-type or Endpoint is implemented by the ODE. Worth case scenario would be a configured on/off switch for P2P interaction. What do you think? Renat On 04.02.10 17:03, "Antoine Toulme" <[email protected]> wrote: Looks like Terry filed ODE-758 for this one. Thanks! Antoine On Thu, Feb 4, 2010 at 00:29, Renat Zubairov <[email protected]>wrote: > Hello Terry, > > I was also looking at this place :) there is actually an if clause in > following lines which is checking wherever p2pProcesses is not null, so if > you would comment out this part may be you should also delete the whole If > statement, however before I would propose to discuss a different options. > Actually in the ODE documentation P2P communication is described as a > feature, not as a bug. It's obviously better from the reliability point of > view that one process sending a message to another process reliably and no > exceptions could happen there, however sometimes it's better that > integration layer would do this "shortcut" instead of delegating it to ODE > core. > Another possible solution would be to determine routing rule not based on > the Service QName but on the Port Name (or QName with WSDL TNS) so that if > any of the deployed processes implements a given Port (not Service) then do > a shorcut. > > Renat > > > On 04.02.10 09:20, "Terry Mueller" <[email protected]> wrote: > > +1 > > I've commented out the following lines in ODEWSProcess.java to get this > to work: > > // if (partnerEndpoint != null) > // p2pProcesses = _server.route(partnerEndpoint.serviceName, > new DbBackedMessageImpl(mexdao.getRequest())); > > Regards, > Terry > > > > On 03/02/10 22:34, Renat Zubairov wrote: > > Hello all, > > > > I have a problem with the Process2Process communication inside the ODE. > Basically I need to implement a BPEL process that uses and implements the > same WSDL. For example I have a service A with two methods request-response > "createEntity" and one way "confirmCreation", I expect my process to call > "createEntity" method and then wait untill the "confirmCreation" method will > be called on it, however since ODE route all MEXes internaly despite the > fact that process actually only implements one single operation > "confirmCreation" I'm getting an MEX expire and failed state. > > > > Would it be possible to fix the P2P communication so that it would only > happen when ODE as a recipient side is able to handle the operation, > otherwise just proceed with a call though Integration Layer. > > > > Renat > > > > > > >
