CPO to CPO communication

[vnamboot]

Hi All,

I need to have two different cpo environments talking (communicating together).

For ex:, Let us say, Parent CPO Platform (which will have load balancer and two or more cpo servers behind it), will need to start a process in Child CPO Platform (which again will have load balancer and may be two or more cpo servers behind it), by passing some input (may be an XML). Then process in Child CPO Platform will perform some operation and send back some response (may be another XML output) back to the Parent CPO platform.

I don't think, I can use the "Create Alert" activity, since it works within only one cpo server. right?

And currently, I am trying out some and R&D using webservice cal.

Parent ------>  Child (Invoking webservice of child cpo with its (child cpo webservice auth: headers) credentials from parent cpo)

Child ------> Parent (Invoking webservice of parent cpo with its (parent cpo webservice auth: headers) credentials from child cpo)

It works fine with the webservice call. Issue is in using the authentication headers which I need to use.

If I am going to have 5-10 child cpo boxes, I need to configure the runtime user (auth: headers) for the parent webservice call in all the child cpo boxes.

And what I am trying to do is, reduce this dependency of configuring runtime users (auth headers). Because, password (auth headers) changes has to be synchronized in all the child cpo boxed as well. The same with child cpo webservice authentication headers. Whenever it is changed, we need to update/configure the respective runtime user in parent cpo box as well.

what I want to try out is to act these two as independent cpo platform, but still able to talk to each other by passing some parameters or inputs to each other, so that any changes in authentication header kind of stuff, doesnt affect the communication between child and parent.

Is there any other way out for this? Or any workaround to acheive this?

Any help/input provided is highly appreciated.

Thanks,

Vijay

[Von Jones]

If this is IAC, I would suggest that you use the change request task as your synchronization point.  When the master CPO receives the service request from the portal, it creates a cchange request.  Typically, this would trigger a fulfillment process on the master.  Instead, create a process that triggers off a new change request on the master and dispatches it to the appropriate child by creating a duplicate change request there through the PO northbound web service.  This would trigger the fulfillment process on the child.  Write a process for the child to trigger of change request changes and send the status and state changes back to the master.

If it's not IAC, I still think tasks are a good manner for achieving synchronization.  Most use cases are centered on change requests, not alerts, though.  But I don't know your use case.

Calling the northbound web service uses the SOAP web service activity. It was my understanding authentication was handled by PO using the runtime user and you didn't need to manipulate the header, but I'm not sure.  In any case, there are several automation pack samples floating around of PO invoking its own NBWS.  I think the IAC content may use this approach to create targets dynamically.

Yes, you will need a runtime user for security to invoke another PO instance.  Since the PO instances are shared, these are discrete objects and would require separate configuration as the password changes. You could put the runtime user in an automation pack and load it into each PO instance, but this may be more work than just connecting to each and changing the password. I believe runtime users can be manipulated through the NBWS if you wanted to automate a password change procedure.

In the next release we will support AMQP which will provide a more elegant manner for master/slave work distribution, allowing children to subscribe to message patterns from the queue, and largely eliminating the need for a master in the design.

[vnamboot]

We are going to use NBWS approach for this.. Thanks a lot for the suggestion

[Svetlana Kryukova · Accepted solution]

Enable Northbound Web Service on both child and master PO installations.

You can then use Web HTTP Request activity (preferred, or Web Service Execute activity, a bit less desirable as it has higher cost) to perform tasks that Von outlined (on a Task Created trigger on the master, you can initiate a process on the master that call Web HTTP Request and either creates a corresponding task on the child or calls a process on the child). Similarly, you can use Web HTTP Request activity from the child to either "resolve" the task on the master or call a process on the master, whatever is appropriate. You can use "External Id" field to store the task id from the master in a task created on the child (or vice versa). This will help you in synchronization between master and child.

There is no need to "manipulate" headers. Create Web Target for the master on all child PO installations. Create Web Targets for each child in the PO installation. If all PO servers are in one domain, you should be able to have Windows User (runtime user) defined within PO server that you can associate that runtime user with the Web Targets created and just use it. If PO servers are in different domains, you may have to use "Basic" authentication for your northbound web service end points, and use simple "Runtime User" credentials. But in either case there is no manipulation of headers required.

[vnamboot]

  Thanks Svetlana... We are using NBWS approach only. Like you said, child PO will have web target for parent. And parent PO will have web targets for all the child