Endpoints/Credentials Configuration

I would like to know, how WM Users have been configuring the end point URLs for webservices and their credentials.

  • Default behavior for end points is for the webservice descriptor (Consumer) taking what ever is mentioned as endpoint in WSDL as the end point info and send a request at that endpoint.
    This obviously cannot be best practice by any standards. Instead, we can put this endpoint information in some properties file and read that file to get the endpoint URL. Is there any out of the box solution in webMethods, where in we can configure properties for projects ?

  • Credentials can be set in the soap operation request. Is that how it should be done? Doesn’t sound all that good to me, though it too can go in properties file. Is there any better way to go about it?

Would appreciate if some one can share what they have done to do this configuration.

There is no such out of box solution for this. The better thing is have the end point and credentials details in configuration files of the package. My personal experience is to have three config files for D, Q and P. Based on the system type, the package startup service picks the right config file and loads into memory. For passwords, you can use stringToBytes → base64Encode and store this string in config file. In the implementation, just do the reverse: base64Decode → bytesToString.
This avoids the need to change these values when deployed to different instances (D,Q and P) and is a one time job.

Cheers
Gunnasekkhaar
http://sekkhaar.blogspot.com

@Gunnasekkhaar
that makes sense…
thanks…

Why should we keep this endpoint Alias and credentials in property File?

Cant we use webService Alias on the IS Admin Console?

Once Alias is created you need to select that Alias on WebService Consumer in Binder Tab.
So your connection information will be controlled by WebService Alias instead of the address present in wsdl. When your Server/ User credentials are changed just update them in Admin console.

Yes you can. but the other approach is to use properties or config files, where the files will be specific to each environment. I have used this in one of the projects that I worked in the past.