We are having intermittent problems using the FIleBasedProject creation API. For some of the created projects we are unable to open in Studio. The error information states:
"The project with ID {0} can not be opened becasue it was not successfully published to the server"
However, the result of the PublishProject() call has a status of PublicationStatus.Published
Why are the projects not openable?
Are there any errors in the Exectution log (or other log files) of GroupShare from the time when the project was published?
Are there any errors in the Exectution log (or other log files) of GroupShare from the time when the project was published?
Paul Filkin | RWS Group
________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
Unknown said:It would be more sensible to use the REST API in GroupShare to support this kind of approach.
Why is Studio being used for this instead of GroupShare?
It's my understanding that
a) their application was created to work with GS2015 where REST API wasn't available, I believe
b) with GS2015 it worked
So these "it's not designed for this" statements sound rather alibistic than like a real arguments :-\
Paul Filkin | RWS Group
________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
Unknown said:6. Fact: the problem they have encountered only started when they went into production
> This program has been running several months since its last modification in both our test and production environments.
From this I actually understand that the program worked in production as well... against GS2015. The problems started only after upgrade to GS2017.
That's how I read the story.
The point I'm trying to make - and I believe it's the original poster's point too - is that there is no reason why things which worked before (although not officially supported... but without real technical reason to not work if known caveats are carefully treated) should not still work.
Plus, there is another aspect - statements like "you should use new API" are not easily done, especially in production. Such statements are usually made by managers who have no idea about the real world... who believe that Rome can be built by simply sending email, or so :-\
That's why people naturally start asking why things which worked before suddenly stop working without a reason.
Unknown said:The point I'm trying to make - and I believe it's the original poster's point too - is that there is no reason why things which worked before (although not officially supported... but without real technical reason to not work if known caveats are carefully treated) should not still work.
Perhaps you can make your point without being so antagonistic. You've said before I should not take things personally but it's very difficult sometimes with the comments you make. You either don't have a very good command of English and use words you don't really understand, or you are just deliberately hostile. I am an optimist so I hope it's not the latter and that you'll improve over time.
There is a very good reason why things may not work when we move from one version to another. The file-based solution is not designed to handle heavy volumes with concurrent processing. It would have been a workaround at best until we provided a similar solution that could be used directly on GroupShare. Any changes that would impact the performance of project creation in Studio could affect the performance of solutions built around the API.
Unknown said:Plus, there is another aspect - statements like "you should use new API" are not easily done, especially in production.
Really!!
Paul Filkin | RWS Group
________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
Translate
