Hello, using XML/HTTP to post data from a source application to the webMethods IS 6.1. As HTTP is a sessionless protocol and if we use username/pwd authentication, I understand each time the source wants to post, it creates a session, posts (including authentication), receives ack and closes session. This would be repeated for each transaction sent, requiring session creation and authentication each time - a potentialy significant overhead. Is there a way we can maintain session information (eg. authentication), such as through a cookie? The IS Admin guide discusses the watt.net.useCookies parameter and describes as ‘Accept (true) or deny (false or null) cookies when communicating with Web servers. It is almost never a good idea to turn this off. Defaults to true’. Is this relevant to the issue? Are there ways to maintain session information between multiple HTTP posts?

Hi John,

Depending on your client application and network connectivity, you may want to consider using the Java or C++ API’s directly into the Integration Server, as this will give you a much more direct “pipe” for your data.

If you have to go the HTTP POST road from your client app, then you will need to manage the session on the client side. The Integration Server uses a session ID cookie (ssnid) to do this - so you will need a manage the “cookie” in your client app and associate it with subsequent requests. To be honest, I’ve never tried turning off watt.net.UseCookies - but my guess is that this would probably expose the session ID through URL rewriting (e.g. http://server:port/invoke/someFolder:someService?jsessionid=989rbe89348hgq34g89hqg9). Of course, this affects everyone who uses the server, and mucks up things like bookmarking so probably not what you really want to do.

If your client app is Java-based, then it is probably easiest to use a third party library in place of the built-in URLConnection classes (as these don’t handle cookies - or at least they never used to, not sure if Java 1.4 introduced any changes there). Check out http://www.innovation.ch/java/HTTPClient/ for a freeware (LGPL) library that is very complete.

Hope this helps.

Cheers,

Steve Ovens

Hi,

By the way, if you set the debug log level on your Integration Server to level 10, you will see the HTTP request data in the IS log, eg.
POST /invoke/FileNet/GetDocumentList_XML
2004-05-13 12:44:29 CEST [ISC.0038.0002V3] ← Accept: /
2004-05-13 12:44:29 CEST [ISC.0038.0002V3] ← content-type: text/xml
2004-05-13 12:44:29 CEST [ISC.0038.0002V3] ← User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
2004-05-13 12:44:29 CEST [ISC.0038.0002V3] ← Host: webmethodsprd:5555
2004-05-13 12:44:29 CEST [ISC.0038.0002V3] ← Cookie: ssnid=258JtbkgxPIZS6TUJ1sHXDg2hYDwU=555652
2004-05-13 12:44:29 CEST [ISC.0038.0002V3] ← Connection: Keep-Alive
2004-05-13 12:44:29 CEST [ISC.0038.0002V3] ← Authorization: Basic U3lzdGVtRWFzeTpFYXN5RWFzeV8x
2004-05-13 12:44:29 CEST [ISC.0038.0002V3] ← Content-Length: 228

This might help with debugging during development.

Cheers,

Steve Ovens

John,

Did you find an answer to your problem? I’m having similar issues where I call a series of web services and even if I pass the cookie information to subsequent web service requests, it still doesnt work. It seems like the authentication information needs to be sent for every web service call.

Hello,

I am going to try to revive this thread since we are facing this need to pass a cookie obtained from a login web service process, to a soapHTTP step in a subsequent flow. Has anyone been able to to this? DO I really need to do this or is it implied/assumed that any subseqent HTTP requests, including soapHTTP, will use the cookie from the prior login.

All the flow steps are in on service flow and I have turned off stateless. Additionally, my watt.net.cookies setting is true.

Here is the basic logic:
Sequence -TRY
Login → call login web service
pull out the cookie string via a map step
getData → call business logic webservice - requires cookie to work.
parse XML and
Logout → call logout web service

Thanks for any help in advance.

regards,

Andrew

I am also facing a similiar issue. We are doing HTTP POST and we need a non cookie based session handling as the client invoking the service can not handle cookies. Any input will be helpfull.

regards
Narasimha

Hello,
arjerem’s approach is a good one. You can have the session handling on the server side. So to start you would have a table for sessions. The table could have a [starttime, expirecount, id, user, password] schema or whatever else makes sense for you. You can start by calling a login service (anonymous, stateless) and have it save and return a useable session id. That should also work to return the same session if you get cut quickly otherwise. With that, you can call a sessionInvoke service that will call any allowed service given a valid session id. The id can be easily set in a hidden form field on web client or an instance variable for app client. Key to this is development on both the client (little) and server (more than little). Good day.

Yemi Bedu.

Andrew,
Have you got the solution for this issue ?
Currently, we ran into the same issue when using webMethods http client to interact with Siebel on Demand server.
In the webservices documentation gven by Siebel OnDemand it says:
The login request is an HTTPS request to instantiate a session and obtain a session ID.
A client invokes login by sending an HTTP GET request to a URL like the following:
https://server_name_here/Services/In…?command=login

Login input.
The input to login is provided in the URL parameters and the HTTP headers, as follows:
■ The only URL parameter to be set is command. This parameter value is login.

■ Two HTTP headers, UserName and Password, must be set with the appropriate values for your
system. For example: