Because of the new Filestore Server architecture, logging in to Vault 2014 takes up more steps than it did before. If you are using the WebServiceManager or Connection object, fell free to skip this article because the extra steps are performed automatically for you. But if you are making direct calls to the web service URLs, then keep reading. I’ll outline the new steps for logging in.
First, make sure you understand the AVFS architecture. Even if everything is installed on the same computer, your code needs to see Vault as two separate servers. The link above also lists which services are on which server.
The SignIn calls are in the AuthService and WinAuthService, which are part of AVFS. If you are showing a login dialog to the user, for example, then the user is expected to type in the name of the Filestore Server, not the Data Server.
If you are logging in with Vault username/password, use the AuthService. If you are logging in with Windows credentials, use WinAuthService. Depending on the needs of your app, use either SignIn(), SignIn2() or SignInReadOnly() to authenticate.
Once you are authenticated, you need to figure out where the Data Server is located. You do this by calling IdentificationService.GetServerIdentities, which returns an array of ServerIdentities. Each ServerIdentity represents a Filestore Server and it’s related Data Server. There may be multiple results if there are multiple filestores installed.
Find the ServerIdentity that matches the filestore you just authenticated to. Remember the DataServer value, because that is the server to call for all web services on the data server.
Once you have it set up so that each web service calls are going to the correct server, you mostly don't have to worry about about the different server types. The glaring exception is file IO, which I explain in my article: File Transfer - Doing it the Hard Way.
Subscribe