In this article, I present a solution for uploading a customization package (zip file containing a desc.xml) using a Java method.
Click here to view the upload customization method code
The method takes three parameters:
The wsBaseUrl must be the <serverURL>:<portnumber> where your WorldServer instance is running.
The second parameter is a security token, which can be retrieved by using the SDL WorldServer REST API as explained here.
The third parameter is the customization zip file containing the compiled customization classes and the XML descriptor file.
This solution relies on the same "management_customization" servlet used by the WorldServer UI for uploading customizations. Certain parameter values (i.e. "comp_type", "submittedBy") are hard-coded to impersonate the UI selection process and allow the upload to proceed.
It is now possible to connect to SDL WorldServer and perform a number of actions by using the WorldServer REST API. The REST API documentation is available from your WorldServer instance by accessing <serverURL>:<portnumber>/ws-api/docs/ws-api-doc-v1.html.
In this article I present a method for connecting to SDL WorldServer and fetching a security token to be used in all subsequent API calls.
Click here to view the login method code
The wsBaseUrl must be the <serverURL>:<portnumber> where your WorldServer instance is running. The login method will append the "/ws-api/v1/login" path required for invoking the REST-based login call.
As mentioned earlier, the call returns a security token to be used in all subsequent API calls.
SDL WorldServer allows customers to expand WorldServer capabilities through pluggable components. There are several exit points in WorldServer through which custom code can be invoked to perform customer-specific operations.Here are the types of pluggable components currently supported:
Developers use the SDL WorldServer Software Development Kit (SDK) to write these pluggable components. The implementation begins by extending an abstract class corresponding to the type of component you want to create. For example, the com.idiominc.wssdk.component.servlet.WSHttpServlet abstract class needs to be extended in order to implement a customized servlet.The abstract classes provide us with a handle to the WSContext object, which provides us with access to the service managers.
I've implemented a very simple servlet for demonstration purposes. I'm using Maven in my project, so I first installed the wssdk-server jar file in my local repository using the following.mvn install:install-file -Dfile=wssdk-server.jar -DgroupId=com.idiominc -DartifactId=wssdk-server -Dversion=126.96.36.19909 -Dpackaging=jarThere are only two dependencies in the pom.xml file.
The ProjectInfo servlet outputs project information from all projects available in the system (active and inactive). It demonstrates the use of the user and workflow managers for gathering information.
I'm absolutely sure that Trados Studio is the most customizable product on the market. To me this a no brainer; all you have to do is to go to the SDL AppStore and have a look at the number of plugins and applications that are available. And that is not all, because there are at least the same number of customizations carried out which are not published on the store because they are built to fulfill a specific need. Depending on the extension or customization you either have something that adds a new options inside Trados Studio or you have an exe that you have to run alongside Trados Studio. In this article I want to talk about this two options and when and why you should choose them.
Both options require software development skills and rely on the same Trados Studio APIs. Deciding which type of extension/customization to build is key in order to provide the best solution to fulfill the user need. If you are looking to publish your application on the SDL AppStore then it is important to know that we encourage publishing of Trados Studio plugins instead of the standalone applications, and for every new extension or customization that is to be published we will not approve it as a standalone application unless there is a strong reason behind it. Of course there are still quite a few of them on the store and we are working to migrate them into plugins where appropriate.
The first version of Trados Studio APIs didn't allow any form of user interface extension so the only option to provide a friendlier experience was to build an application that ran alongside Trados Studio.
Plugins were around from the first version of the Trados Studio APIs but didn't support any form of user interface extension until the introduction of the Integration API.
To my mind most of the times building a plugin for Trados Studio should be the go to option most of the time. Although there are though situations where a standalone application is needed, like the SDL Analyse where we wanted to give the user the ability to run an analysis outside Trados Studio.
Please leave a comment with your thoughts, ideas and suggestions.
I decided to write this article after I got a question on my last blog article, SDL Studio plugin manifest, about an issue with files that are overridden during an SDL Studio plugin build. Although this issue is quite specific I received questions with similar situations from other people and the root cause of this problem is related to how you manage SDL Studio plugin dependencies, or, in other words, how you manage the assemblies that are copied in the output folder of the plugin.
To better understand the problem I need to explain what is happening when an SDL Studio plugin is generated from Microsoft Visual Studio. By default Visual Studio generates dll files for the projects you have in your solution when you select a build action. To be more accurate all that Visual Studio does is to run MSBuild which is the Microsoft Build Engine that is responsible for producing the assemblies, out of your source code and projects. Some of you might know already but for those of you who don't know an .sdlplugin file is not a dll, rather it's a specialized archive that could potentially contain one or more assemblies (dlls) and some other resources. So it's pretty clear that the .sdlplugin file is not produced by Visual Studio with a default setup.
A few months ago I've written an article about the SDL Studio SDK in which I explained about the SDL Studio project templates for Visual Studio. These project templates extend the standard project build process from Visual Studio by adding another step which generates the .sdplugin file. So the workflow to generate the plugin package is something like generate the dlls and then based on what you've specified in the plugin manifest generate the .sdplugin package.
If you really want to know where the magic happens, you should open your plugin .csproj file (which is just a specialized xml file) with your favourite text editor and scroll down the bottom where you should find a line similar to the one in the screenshot:
If you run the build for your plugin and then you look in the output location, you might be surprised to find that you have a lot of files (I have had around 200 files for one plugin). This might come as a surprise since your plugin might only depend on a few assemblies. So from where are all these files/dlls coming from? Can these files cause any harm (this is the issue in my previous article)? Can I avoid having these files copied at all?
These files come from the SDL Studio install location and are copied over because your plugin depends on some Studio APIs that internally depends on these files. So, in other words, they are dependencies of your plugin dependencies. The problem with these files is that they are useless since the plugin will be loaded by SDL Studio and all this dependency will be resolved at runtime from the SDL Studio install location. On top of that you might want to use a newer version of a particular library that is also used by SDL Studio but all of a sudden you realize that during the build this is overridden with the version that was deployed with SDL Studio. All of this is happening because of Microsoft Visual Studio default behaviour.
The solution is quite simple and requires just a few clicks:
Open your plugin solution in Microsoft Visual Studio and expand your plugin project.
Under the project you should find a References section you can also expand.
Select all SDL Studio API assemblies that are used in your plugin and then right-click and select Properties.
After those steps the dependencies will no longer be copied over which will result in a cleaner output location, faster build and avoid duplicate library version issues.
If you have any questions don't hesitate to leave a comment.