Trados Studio 2019 API, FileBasedProject + Groupshare - Expired token, unexpected exception, could not instantiate translation engine.

Question

Dear SDL Devs, dear community, 
 
 we are currently running into the following issue: 
 Our Code uses an existing FileBasedProject. When updating the project credentials or TM settings we get the following exception: 
 Die &Uuml;bersetzungs-Engine 'sdltm. groupshare.OURURL.com/ (US) - German (Germany)' konnte nicht instanziiert werden.. 
 TMService.log shows the following problem: 
 2019-09-02 14:09:00.1913|SDLGROUPSHARE|Warn|THREAD_ID:23|TR_ID:OURIDHERE| Unauthorized request 2019-09-02 14:09:00.2382|SDLGROUPSHARE|Warn|THREAD_ID:23|TR_ID:ANOTHERIDHERE| Authentication failed: The message expired at 30.08.2019 10:46:44 and it is now 02.09.2019 14:09:00. 
 SDL Application.log shows the following problem: 
 2019-09-02 14:12:15.726#SecurityHandler.OAuthTokenHandler#DotNetOpenAuth.Messaging.ProtocolFaultResponseException: The message expired at 27.07.2019 01:56:48 and it is now 02.09.2019 14:12:15. ---> DotNetOpenAuth.Messaging.Bindings.ExpiredMessageException: The message expired at 27.07.2019 01:56:48 and it is now 02.09.2019 14:12:15. bei DotNetOpenAuth.OAuth2.AccessToken.EnsureValidMessage() bei DotNetOpenAuth.Messaging.DataBag.DotNetOpenAuth.Messaging.IMessage.EnsureValidMessage() bei DotNetOpenAuth.Messaging.MessageSerializer.Deserialize(IDictionary`2 fields, MessageDictionary messageDictionary) bei DotNetOpenAuth.Messaging.UriStyleMessageFormatter`1.DeserializeCore(T message, Byte[] data) bei DotNetOpenAuth.Messaging.DataBagFormatterBase`1.Deserialize(T message, String value, IProtocolMessage containingMessage, String messagePartName) bei DotNetOpenAuth.OAuth2.StandardAccessTokenAnalyzer.DeserializeAccessToken(IDirectedProtocolMessage message, String accessToken) bei DotNetOpenAuth.OAuth2.ResourceServer.GetAccessToken(HttpRequestBase httpRequestInfo, String[] requiredScopes) --- Ende der internen Ausnahmestapel&uuml;berwachung --- bei DotNetOpenAuth.OAuth2.ResourceServer.GetAccessToken(HttpRequestBase httpRequestInfo, String[] requiredScopes) bei DotNetOpenAuth.OAuth2.ResourceServer.GetAccessToken(HttpRequestMessage request, String[] requiredScopes) bei Sdl.StudioServer.Authorization.SecurityHandler.OAuthTokenHandler.SetThreadIdentity(HttpRequestMessage request) 
 
 The token seems to expire after 12 hours, but we did not measure the exact amount of time.

Can you check if we run into the same problem (expiring tokens) that was discussed previously here: https://gateway.sdl.com/apex/communityknowledge?articleName=000006236 ? 
 Do you have any other suggestions that we can try, besides following the instructions from https://gist.github.com/cromica/e1a976fdfdc821136c7610b5e984904e (we checked already for code similarity)? 
 At the moment it's not feasible for us to use https://github.com/sdl/groupsharekit.net since we have a huge code base, so refactoring to GS kit would be quite an effort.

Best regards from W&uuml;rzburg, Germany, 
 Hendrik 
 
 We work with FileBasesProject based on Project Automation API in Trados Studio 2019 SR 2 15.2.0.1041. 
 We use Groupshare-based TMs on our own hosted Groupshare-Server running UI: 14.1.10 GS: 14.2.60175.10 - SR1 CU10.

Patrick Andrew Hartnett · Accepted Answer

Hi Hendrik Striepe , I have been reviewing this issue during the last days and confirm that I was eventually successful in reproducing the exception that you mentioned, but only once. 
 Note: I couldn&rsquo;t identify anything that is incorrect from the code changes that you applied with your version of the automation app, apart from the multiple attempts to save the project, which isn&rsquo;t necessary for the tests performed. In all cases, it is unlikely that the multiple attempts to save the project is the cause of the exception, as it occurs further up the stack. 
 Test-case setup: 
 
 Imported the TM resources that you provided on a GS 2020 server with the same configuration; making reference to the template you used. 
 Created a new project template with multiple languages, that also include references to the same server based TM resources. 
 Used the same version of the ProjectCreator.cs 
 
 Results: 
 I performed multiple attempts (100/s) over a period of a few days with various configurations, elapse times, including leaving the automation run over night, thereby fulfilling the requirements of the 12 hour elapse time scenario. During that time, I was able to reproduce the exception once and quite unexpectedly, straight away after I launched the automation standalone app 
 One thing to make note of here is: the automation test-case where the exception was invoked, only occurred once and all successive attempts in the same automation instance were successful. This means that we could potentially introduce logic to manage failed attempts given the exception type; possibly implemented on the client code as a workaround&hellip; initially 
 
 Studio: Investigation 
 Continue our investigation to better understand what is causing this exception; tracking nr.: LG-29871 
 
 Workaround 
 Until time that we understand better how to reproduce this issue and what is in fact causing it; which might be unrelated to the credential token & 12 hours elapsing. I recommend the following: 
 Given the test-case where I was able to reproduce this exception once and all successive attempts being successful. You could introduce logic to encapsulate the execution to the project automation to restart the procedure on a failed attempt (or attempts); potentially identifying also the exception type from the content we have seen thus far.

Romulus Crisan (former member) · Answer

Hendrik Striepe Kleio Mavridou 
 Would it be possible to send me a sample application and project where the problem is appearing? If don't want to share them in the community you can write them directly on my email rocrisan@sdl.com 
 Also can you please let me know what type of authentication you are using on the GS instance?

GroupShare Developers > GroupShare Developers forum

Trados Studio 2019 API, FileBasedProject + Groupshare -> Expired token, unexpected exception, could not instantiate translation engine.

Top Replies