We are attempting to communicate with our VAN (who uses Cyclone) via EDIINT AS2 on webMethods 6.0.1. We have partially managed to get outbound communication working, though we never get back an MDN from the VAN(either synchronous or asychronous). But when the VAN attempts to send inbound to us, they get back the following response:
Unable to send. java.lang.Exception: Command:POST, Expected:200, Response:401
In my experience, 401 always means that the request requires user authentication. We are using digital certificates, and have mapped the VAN’s client cert to a valid userid within webMethods. I thought that would be enough. Now I’m wondering if they need to send a username and password too? But the problem there is that Cyclone does not (according to them) offer a place to input a username and password.
To further complicate matters, they are coming in through our Proxy server. After working with our network guy and setting up a sniffer trace, he says that the 401 error is being returned to the VAN from the Integration Server, not the Proxy. But I’m not so sure, because I couldn’t find any mention of this error in any of the IS logs.
So we’re fairly stuck at this point. Has anyone run in to anything similiar to this? Any and all comments/ideas/suggestions are very welcome. Thanks.
Thanks for the response. I actually already had them try posting using the same url format you suggested. I’m not sure which version of Cyclone they’re using, but when my contact there pasted in the new url format (with username and password embedded) and saved, the “username:password@” was removed from the URL…looks like some sort of validation that Cyclone does.
Igor is saying that username/password is not required? And the original poster seems to be having a very similiar problem to the one we are experiencing.
The normal operating protocol for handling embedded name and passwords in URLs is to extract it and submit them in a protocol specific manner. For HTTP this typically involves the following:
strip out the name and password from the URL
attempt to perform the HTTP operation
if you get a 401, retry the operation using the guidance in the HTTP WWW-Authenticate header. The new request includes an Authorization header with the name & password in a format based off of the scheme from the WWW-Authenticate header.
Browsers will typically short-circuit #2 if a prior request resulted in a 401 and a realm/domain is set that establishes which URLs require credentials.
Looks like I may not be able to help you. IBM says that they have their own track for Cyclone development and have access to features and settings before they’re made available in the shrink-wrap versions.
Has anyone else here successfully integrated Cyclone with webMethods? I really think that my problem stems from the fact that Cyclone doesn’t seem to have a place to fill in a userid and password. Can anyone offer any insight on this?
We had the same issue, but we have managed to succesfully integrate Cyclone with webMethods. We even had someone from Cyclone coming over to us to help us out. According to him, the username/password is the reason for the failure. On his advise we dropped the username/password authentication (changed the wm.EDIINT:receive ACL to Anonymous). It is not much of an authentication anyway, because the password is sent in plain text over the internet. It seems that even the AS2 standards do not recommend user/passwd usage.
We did the exact same thing right from the start so I never saw the 401 error and therefore never made the association with your problem.
One of the things I would recommend for EDIINT testing is to send an email to demo@webmethods.com and test your EDIINT setup with them first to work out the kinks before testing with your partners.
The service is free.
Very good. Thanks for all the comments gentlemen. Changing the ACL to Anonymous works like a charm. It initially made me uncomfortable to do this, but I agree with Andre: since it’s sent in plain text, it’s not much of a security measure anyways.
I was a bit uncomfortable too about the Anonymous ACL, but we’re using a Reverse Invoke server to connect to the internal IS. This way, nobody has direct access to the IS from the Internet. Apart from this, all AS2 data is signed and encrypted, and thanks to WmEDIINT Fix 1, TN will only accept signed and encrypted messages. Make sure you have this fix! There is not much that can go wrong, only messages from known partners are processed.
That’s the way I set it up. When doing my initial testing with webMethods Demo centre we encountered these issues and the fix was implemented. All of our documents are signed and encrypted also.
I don’t work for webMethods but I really appreciate the value of that demo centre in getting the processed worked out before hitting the customer.