topic Re: WebServiceManager Soap 300 in Vault Customization Forum

WebServiceManager Soap 300

wannensn — Mon, 18 Feb 2013 15:14:52 GMT

Hi,

I get a Soap 300 error calling

WebServiceManager.CustomEntityService.GetAllCustomEntityDefinitions()

I thought that all Soap 300 errors are managed by the WebServiceManager!?

Thanks, Stephan

Re: WebServiceManager Soap 300

Redmond.D — Wed, 20 Feb 2013 12:56:55 GMT

The WebServiceManager attempts to fix error 300. There is always the possibility that the fix doesn't work.

Is this a one-time error, or does it happen reliably? Feel free to post a code snippet if you want me to take a look.

Re: WebServiceManager Soap 300

wannensn — Wed, 20 Feb 2013 16:09:11 GMT

Hi Doug,

I use the WebServiceManager in a Vault Extension. During LogOn I initalize the WebServiceManger. When theVaultExplorer is loaded completely I restart the WWW-Service on the server.

After that I LogOut from Vault and in the LogOut function I use the

GetAllCustomEntityDefinitions() to save some data about the custom entities on the client pc. Thats where the error occures.

I can also force a SOAP 300 exception when I use my extension. Then the error occures using the

GetSystemOption() function.

Thanks,

Stephan

Re: WebServiceManager Soap 300

Redmond.D — Wed, 20 Feb 2013 17:43:11 GMT

Ah, I see, you are running inside Vault Explorer. There is a footnote to the re-sign in feature, it only works for credential classes that support SignIn. The UserIdTicketCredentials does not support SignIn. The WebServiceManager can't do anything here because userId and ticket are not enough to perform a sign in.

I believe that UserPasswordCredentials and WinAuthCredentials are the only ones that support re-sign in.

We are working to address the issue of re-sign in within a Vault plug-in.

Re: WebServiceManager Soap 300

wannensn — Thu, 21 Feb 2013 07:40:48 GMT

Did I get that right. I have no chance to recover from a SOAP 300 error within a vault explorer extension?

--Stephan

Re: WebServiceManager Soap 300

Redmond.D — Thu, 21 Feb 2013 12:49:46 GMT

Correct, there is no way to recover. At least for you current operation. Every time your plug-in is called, a Vault Context is passed in, which contains the latest user ID and ticket information. So one workaround is to just create a new WebServiceManager for each call.

Re: WebServiceManager Soap 300

wannensn — Mon, 11 Mar 2013 13:00:45 GMT

This will only work when VE detects the SOAP 300 error an recovers from it. Otherwise the context is still invalid.

--Stephan

Re: WebServiceManager Soap 300

Anonymous — Mon, 16 Sep 2013 12:07:51 GMT

Auchh.. Just experienced this one after fixing this other one:

http://forums.autodesk.com/t5/Autodesk-Vault-Customization/OH-NO-My-plugin-is-eating-licenses/td-p/4383500

Is this history in the 2014 API ?

Re: WebServiceManager Soap 300

Anonymous — Mon, 16 Sep 2013 14:48:39 GMT

I´m curious about a workaround that doesn´t involve a new instantiation of webservicemanager for every call.

( vault 2013 API )

Will this simple implementation ( or something close ) do the job or do I need to wrap every call in a try/catch to be sure to handle the 300 correctly?

private WebServiceManger _webServiceManger
private WebServiceManger
{
get
{
if(_webServiceManager == null)
_webServiceManger = new WebServiceManger(login); // UserIdTicketCredentials
return _webServiceManger;
}
}

Re: WebServiceManager Soap 300

Redmond.D — Tue, 17 Sep 2013 13:39:31 GMT

You should be wrapping everything in a try/catch block anyway. The recommended fix is to bubble the error up to the user an let them run the command again. Have a look at this article: http://blog.coolorange.com/2013/03/25/handle-soapexception-300-badauthenticationtoken-in-vault-extensions/

Note: This issue should be fixed in 2014 because each execute event passes in a Connection object, which has a WebServiceManager. That way you don't need to manage your own WebServiceManager. Instead, you share the same one that Vault Explorer uses.

Re: WebServiceManager Soap 300

Anonymous — Tue, 17 Sep 2013 18:53:09 GMT

Thanks for your reply and - yes - fair enough about the try/catching everything..

I stumbled over the article you mention earlier, as the issue seems to be bit of niche, but my scenario is a slightly different ballgame, so ATM I wrap every call that has context in a method, so I can call it repeatedly without loosing context, should an exception be thrown. I was wondering if I was making to much of a fuzz..

Now the catch is not delivering a never ending story 😉