Cookies and the soap plugin

[colinj]

Howdy all,

I'm using the SOAP plugin to make calls to the Bluecat Networks Proteus API for IP management. From the Proteus documentation

Proteus uses cookies to maintain state. When using WSDL-generated classes, be sure to enable cookies
on your system.

So I'm wondering if there's some way to enable cookies either in the SOAP plugin or within Orchestrator itself.

I'm currently running VCO 4.2.1

please and thank you.

colin j.

[sanchezs]

Hi Colin,

The SOAP plug-in is configured internally to have a cookie management policy similar to the most common browsers, or at least that's what the Apache HTTPClient 3.1 CookiePolicy.BROWSER_COMPATIBILITY option claims to do

See http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/cookie/CookiePolicy.html#B...

In any case, if you experience any issue with the cookie management in your specific scenario, don't hesitate to ask.

I hope it helps.

Sergio

[colinj]

So what I'm trying to do is to interact with a Bluecat Proteus server. I've successfully used to SOAP plugin to consume the WSDL that the server provides and I can see all of the relevant methods and create workflows from each of them. So far, so good. Now, the prescribed method for interacting with the Proteus server is something like:

Call Login method

Call some other methods to do something

Call Logout method

If I construct workflows for each method and try and string them together the login method works but as soon as I hit the next method workflow I get an error about not being logged in. So somewhere that login/cookie information is getting lost.

If I create workflow A which calls workflows B and C and workflow B calls a remote service that returns some cookies to be stored does workflow C have access to those cookies? How are cookies passed from one workflow to the next in any sort of workflow chain?

thanks

colin j

[sanchezs · Accepted solution]

Hi Colin,

Sorry, I was not clear enough with my first answer. The cookie management (session management basically) is done in a browser style within the same scripting block, inside a workflow, but not between different workflows.

For your specific case there are a couple of possible solutions:

• Generate different workflows for the different operations that you want to invoke and edit the "Scripting" element on each of them to invoke the login and logout methods before and after. The important is to reuse the same host instance inside all the scripting block, and of course you can invoke as many operations as you want between the login and logout operations. Something like:

var host = Server.findForType("SOAP:Host", "f1d035e8...");

var loginOperation = host.getOperation("login");
var request1 = loginOperation.createSOAPRequest();
request1.set...
var response1 = loginOperation.invoke(request1);
response1.get...

// some stuff here

var operationX = host.getOperation("operationX");
var request2 = operationX.createSOAPRequest();
request2.set...
var response2 = operationX.invoke(request2);
response2.get...

// some more stuff here

var logoutOperation = host.getOperation("logout");
var request3 = logoutOperation.createSOAPRequest();
request3.set...
var response3 = logoutOperation.invoke(request3);
response3.get...

• Generate a workflow for the login/logout operations (and for all the rest operations that you want), and pass the output authentication headers of the login workflow to the other workflows that require authentication. You can use the methods SOAPResponse.getOutHeader...(...) and SOAPRequest.addInHeader...(...) to achieve that, but you need to modify the generated workflows to add the proper output or input parameters.

The advantage of the model session per scripting block is that users don't need to care about opening and closing the session, the drawback is that you need to edit the generated workflows in cases like yours. In any case it doesn't seem a bad idea to study the possibility of including operations to manually open and close sessions for the next releases of the plug-in.

I hope it helps.

Sergio

[OsburnM]

I realize this is an older post but I'm starting to get involved with connecting vRO to our Bluecat IPAM solution and I'm finding the plugin is sorely lacking.  Seems absorbing the WSDL & using SOAP may be the better way to go; however, I'm not clear how to pass the authentication token between workflows & script tasks.  I thought about the second option of just embedding the login/out into each script task but that would mean having to create the username/password and I'd like to keep that limited to just the login/out workflows.

Can you clarify what you mean with this?

You can use the methods SOAPResponse.getOutHeader...(...) and SOAPRequest.addInHeader...(...) to achieve that, but you need to modify the generated workflows to add the proper output or input parameters.

Thank you very much for your time!