Unable to publish a project to GroupShare usign FileBasedProject.PublishProject

While building a tool to automate the creation and publishing of projects to GroupShare, I've found that I'm unable to publish projects to GroupShare.

The process first of all creates an organisation to which it will upload the project; then it does the project upload.

    var orgId = await CreateGroupShareOrg(order.Id, progress);

    Log.Info($"{nameof(UploadPackageToGroupShare)}: organisation \"{order.Id}\" created on GroupShare.");

    project.PublishProject(
        new Uri(@"groupshare-srvr.our-website.com/"),
        false,
        "--username--",
        "--password--",
        $"/Projects/{order.Id}",
        (obj, evt) =>
        {
            Log.Info($"{nameof(UploadPackageToGroupShare)}: {evt.StatusMessage} {evt.PercentComplete}% complete");
        });

You can see that the goings-on are being logged, and from this I can tell that the organisation is being created - I can verify this by looking in the SDLSystem DB and finding sts.ResourceGroup.resourceGroupPath matching the new organisation's name, and the corresponding resourceGroupGuid matching the returned GUID. So the call to CreateGroupShareOrg is operating as expected.

But the call to FileBasedProject.PublishProject is unsuccessful - it returns a 404, and I can't figure out why. I've tried variations of the URL (with and without "/groupshare" on the end of the URL, and with/without adding ":80" on the end).

Also, the same URL and login details are used in CreateGroupShareOrg, although that method goes via GroupShareKit.

The event in the final parameter always records simply

    "UploadPackageToGroupShare:  0% complete"

We've had this working in the past and I've seen it record maybe 10 entries, each with an incrementing percentage. As far as I'm aware, none of this code has been changed since it was last seen working.

Here's a Fiddler trace which might explain something that I've missed. Row #9 is the request to publish the project.

#ResultProtocolHostURLBodyContent-TypeRequestMethod
2 200 HTTPS www.our-website.com /filedownloads/file/619596/TEST-UPLOAD.txt 135 application/octet-stream GET
3 200 HTTP groupshare-srvr.our-website.com /management/api/1.0/organizations?flatten=true 1,967 application/json; charset=utf-8 GET
4 200 HTTP Tunnel to www.our-website.com:443 0 CONNECT
5 200 HTTPS www.our-website.com /api/v1/Order/termbases/103054/Company%20Website 0 PUT
6 200 HTTP groupshare-srvr.our-website.com /management/api/1.0/organizations?flatten=true 1,967 application/json; charset=utf-8 GET
7 200 HTTP groupshare-srvr.our-website.com /management/api/1.0/organizations?flatten=true 1,967 application/json; charset=utf-8 GET
8 200 HTTP groupshare-srvr.our-website.com /management/api/1.0/organizations 38 application/json; charset=utf-8 POST
9 404 HTTP groupshare-srvr.our-website.com /platform/sdl/discovery.svc 0   POST
10 200 HTTP Tunnel to www.our-website.com:443 0 CONNECT
11 204 HTTPS www.our-website.com /api/v1/admin/package/id/103054/1 0 GET
14 200 HTTP Tunnel to www.our-website.com:443 0 CONNECT
15 200 HTTPS www.our-website.com /api/v1/admin/package/report/103054/ 0 POST

One last point: I am able to create and upload a project usign Trados; the only difference is that Trados doesn't create the organisation as part of the process.

So what's going wrong? Why am I unable to upload/publish a project?

Parents Reply Children
  • Hi Laurent,

    GroupShare v4.0.4267.0

    I'm using "Custom" authentication which we've had signed by SDL. It's the same user details which I use to log in to GroupShare's web UI, and the same login is also being used to successfully get TMs, create organisations, etc.

    However, since originally writing the above post I've realised that the PublishProject method returns an object with a result message and exposes an exception property. From this I've found the result message

       Failed to publish the project.

    And the exception reveals

       No credentials specified for server '[my GroupShare server URL]'.

    The confusing part is that when I've tried publishing the project to a different GroupShare server (not my company's but an SDL demo GroupShare installation) the same code successfully published without this credentials problem.

    So then I read the documentation relating to adding credentials, specifically the ProjectCredentials.AddCredential(Uri, Boolean, String, String) method, which has very little in the way of remarks or guidance... unlike the ProjectCredentials.AddCredential(Uri, String) overload which has this to say:
     
        It is recommended to build the URIs using the TranslationProviderUriBuilder class.
     
        GroupShare Project Server: For a server-based project, an entry should be added for the project server itself. The URI should be
        of the form "ps.http[s]://HOSTNAME:PORT".
     
    I'm not quite sure what to do with the TranslationProviderUriBuilder class or what are the benefits. I built an object and specified all the properties on this, but AddCredential still expects a standard Uri object, so I'm not sure what advantage the TranslationProviderUriBuilder class offers.

    However, when I specified
     
        var uri = new TranslationProviderUriBuilder(new Uri(@"ps.http:// ... :80"));
        uri.UserName = "[my username]";
        uri.Password = "[my password]";
        uri.Type = "Custom";
     
    An exception is thrown:
     
        System.InvalidOperationException: The current parameters are not compatible with the Translation Provider Uri Schema
            at Sdl.LanguagePlatform.TranslationMemoryApi.TranslationProviderUriBuilder.BuildUri()
            at Sdl.LanguagePlatform.TranslationMemoryApi.TranslationProviderUriBuilder.get_Uri()
     
    So I tried simply specifying the credentials without using the TranslationProviderUriBuilder class:
     
        project.Credentials.AddCredential(new Uri(@"[my GroupShare server URL]"), false, "[my username]", "[my password]");
     
    And the result?
     
        "Failed to publish the project."
        "No credentials specified for server '[my GroupShare server URL]'.
     
    I welcome any suggestions.
  • The issue is caused by a limitation in the ProjectCredentials.AddCredential method from the Studio Project Automation API. Unfortunately this method doesn't support url's with additional paths. So if your GroupShare would be installed under http://groushareserver all should work fine but it will not work for http://groupshareserver/path. I've raised this internally as an issue and until this is fixed the solution is to expose groupshare under an url without paths. 

    Romulus Crisan | Translation Productivity Development Manager | SDL | (twitter) @cromica_82 | (blog) http://www.romuluscrisan.com/