Shaun,

Thanks for raising this.  The exception thrown from project API implementation is a bug we are looking into fixing to ensure any exception as least contains useful information.  Additionally, the current API does not expose any option to control reimporting/processing of the return package.  SDL are also looking into adding this feature and I will feed back on this as the investigation continues.

Regards, Ian

Ian Davies  |  Senior Product Manager | SDL | Language Technologies Division |  +44 7826843819

Shaun,

Thanks for raising this.  The exception thrown from project API implementation is a bug we are looking into fixing to ensure any exception as least contains useful information.  Additionally, the current API does not expose any option to control reimporting/processing of the return package.  SDL are also looking into adding this feature and I will feed back on this as the investigation continues.

Regards, Ian

Ian Davies  |  Senior Product Manager | SDL | Language Technologies Division |  +44 7826843819

Hi Paul,

Was there any further update on this? I am using 2014 SDK and I am seeing the same message as Shaun and until now I wasn't able to figure out a proper workaround.

Thanks,
Marek

Hi Marek,

in this thread I've suggested a possible issue for a similar problem. Would you be able to test and let me know what is happening ?

Thanks.

Hi Romulus,

You have replied in my thread, and that reminded me that i was going to reply to you and forgot about that.

Unfortunately, exception is thrown in Sdl.ProjectApi.Implementation.PackageOperation.get_Files() . that means functions actually terminates there and returns nothing in event handlers

Can we somehow merge this two threads or close one of them with link to  the other?

The statusEventHandler  is used to report progress of the import. The crash it's actually at the end of this process. So my guess is that if you specify a method handler for the statusEventHandler it should enter in that method a couple of times until you have the crash.

I manage to reproduce your crash and there are 2 aspects of this issue:

First of all there is a defect in the SDK because it shouldn't crash as it is. There is specific logic written for setting the failed status but is not working correctly. I will raise this with the development team because this should actually pass the correct status via the status event handler.

Regardless of the above crash Studio SDK is not allowing to import the same return package more than once and it there is specific logic written for this. The crash is a side effect of this logic. I know that  Studio application is asking if you want to override the previous import but this behavior is not available in the SDK and I can't say if will ever be implemented.

This leaves us with 2 options:

1. You ask for a new return package. Every time the return package is generated by the translator it will have a unique identifier so you will not encounter the above issue.

2. The second option is of last resort and only if the first option is not viable. This is because this is not officially supported in any way. So if you really need to do this you will have to manually parse your *.sdlproj and remove ReturnPackageImport xml element. This xml element has a PackageGuid attribute which you should compare against your return packageGuid and if the same remove ReturnPackageImport xml element from *.sdlproj.

As I've said the second option is not supported and you might encounter some unexpected behavior.

I have an additional question and it seems like this topic ist the right place for it [:)]

Our main scenario is that we are sending an sdlppx package to a translator. The translator translates the package, generates a sdlrpx package and sends it back to us (via web upload). Behind the upload form there is an automated import process, which imports the sdlrpx package into the project (sdlproj). For the first upload, the import works fine.

After the import, we have several quality assurance processes (automatic and / or manual). At this point, we make a decision whether the quality of the delivery is OK or not. If the quality is too bad, the delivery will be rejected and the translator will be informed to correct the delivery. Then, he needs to send a new sdlrpx package (there is no new sdlppx generated on our side when the delivery is rejected).

When the translators uploads the corrected sdlrpx and we do the import again via SDK, the import fails because there has already been a previous import.

So what do we need to do, so that the second delivery (or any later delivery) will be processed successfully?

• Do we need to generate a new sdlppx package for the translator when we send the job back to him?
• Do we need to reset anything inside the project (e.g. paragraph states, ...) before importing, or even before packing the sdlppx?
• Is there anything else?