WebServiceManager Soap 300

[wannensn]

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

[Redmond.D]

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.

[wannensn]

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

[Redmond.D]

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.

[wannensn]

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

--Stephan

[Redmond.D]

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. 

[wannensn]

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

--Stephan

[Anonymous]

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/4...

Is this history in the 2014 API ?

[Anonymous]

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;
}
}

[Redmond.D]

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-exten...

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.

[Anonymous]

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 😉