Oddjob

Oddjob is a basic version control system. It ensures that only one user can work with a particular file at a time. It tracks Assets. Each asset represents a file and its metadata.

When you receive a file called Foo.bar and, at same point in the future, you receive another file called Foo.bar, which is basically the same file like the previous one but with some changes (be they linguistic or technical, like tags etc.), you want to make sure that you do not translate the file twice. Oddjob assigns each file a property called AssetID during Import. AssetID is a string that is the same for all versions of one file. So our Foo.bar file gets assigned AssetID e.g. OJ100000007 and any subsequent version of Foo.bar will have the same AssetID OJ100000007. If you search for this AssetID, you will get a list of all Foo.bar versions with their corresponding metadata. What happens when Foo.bar version 1 is not yet translated and Oddjob receives Foo.bar version 2? The version 2 will become a Pending Asset and you get to decide whether you want to proceed with the update or you want to wait for the version 1 to be translated first. Once the version 2 is safe to be translated, call the Asset Pending Import action (GET /api/AssetsPending/{id}/Import) and version 2 becomes the active asset. Whether an asset is active or not is specified in the IsActive property. Only one version is active at a time. How does Oddjob know that Foo.bar is a version of Foo.bar and not a completely new Foo.bar file? Well, you have to tell Oddjob just that during the Import! It's all based on the StringAssetIdShouldBeGeneratedFrom property. In our example maybe our Foo.bar gets always received in a particular forlder structure (e.g. Foo/Bar/Foo.bar) so we can put that in the property. Another case might be an external identifier from the client - e.g a guid or id from their system that can tell us that Foo.bar and Foo.bar are modified versions of each other. If your client does not care about this functionality, just generate a random guid into this property - this will ensure that no versioning is applied.

If you need to perform any action on a particular asset that requires an exclusive access to it, you should check-out (GET /api/Assets/{id}/Out/{status}) the asset. Once you have performed the necessary changes, check-in (POST /api/Assets/In) the asset back. Of course you can also undo check-out (GET /api/Assets/{id}/Undo), which just releases the exclusive lock from the asset.

Sometimes you receive an asset that is not in a localizable format (e.g. image, video etc.). In that case you can extract the translation string into a different file and link it to the parent non-localizable asset. We call these files Meta Files.

Cloud Assets are Assets that are uploaded in a translatable format into a TMS (Memsource). They have an analysis so you can find out the effort and cost of each asset. There is a strict 1-1 relation between an Asset and a Cloud Asset.

During Import each asset gets assigned a primary key called AssetPKID . Using this id you can track every step of a particular asset. You can see its history , cloud asset , meta file , tags etc. The AssetPKID is also needed for all the basic actions like check-out , check-in , undo check-out etc. Every asset belongs to one specific target language. The primary language code in Oddjob is LCID as defined by Microsoft here The OddjobLanguage object gives you mapping to additional language definitions (e.g. ll-lc).

To use the API, your account needs to have granted the access via ACMAN. Once you have access, you log in using the Login (POST /api/Login) controller or by creating a new client on RWS Moravia Login that has the scope oddjob-api. Once you get the access token, just add it to the Authorization header of your HTTP request in the following format: Bearer {access_token}.

There is a number of actions that might take a lot of time to process and your API request could time out before completion. To work around that, we have something called Async object. Instead of immediately processing your request, the API gives you and id of an async request registered in the system. Once registered, the API sends a message via ServiceLayer to a background service that actually processes your request and persists the result back to the Async object for you to read. You can check the result of such operation by calling the Async status endpoint with the Async id you received in the response. Operations that use the Async pattern are:

• Import
• Check-Out
• Check-In
• Undo Check-Out
• Delete
• Import Meta File
• Import Pending Asset
• Upload to Cloud
• Cloud Asset Pre-translation
• Cloud Asset Analysis

To upload a file to Oddjob, use the Files endpoint . The file must be encoded using the multipart/form-data. A successful uploads gives you a FileOid, an unique identifier that you can use in other actions: Import , Check-In and Import Meta File .) Please note that you can upload a ZIP file with multiple files. Each file gets its own FileOid assigned. When a FileOid is successfully used in any API action, it gets automatically deleted from the server. Any subsequent call using the same FileOid will result in "The file oid does not exist on the server" exception.

Here is a definition of all the Asset Import properties:

• *FileUploadOid - guid returned by the Files endpoint.
• *StringAssetIdShouldBeGeneratedFrom - string that AssetID will be generated from - see Versioning.
• *ProjectId - Id of the OddjobProject the Asset belongs to.
• AssetID (will be generated by Oddjob) - version identifier - all assets versions can be tracked using this Id.
• *LCID - target language identifier, details here.
• LocPath - originally this was the folder structure in what the file was received from the client but you can put any useful information that belongs to the file.
• *HandoffName - batch name in which a set of files was received - can be a date, a year, can be whatever logic you project might need to group particular files into.
• *StatusName - status in which the file should appear after import.
• *FileName - name of the file.
• *Version - version name. If left empty, it is automatically replaced with v1,v2,v3...vN based on the version number in the system (please see the versioning section for more details). If you want to use the auto-increment value but want to format it differently, please use the following format: %v this string will be replaced by version number during import so you can append it to any string.
• Priority - priority of the file.
• ClientDeadline - deadline received by the client.
• MoraviaDeadline - internal deadline that we want to use.
• *IsMtOnly - specify if the file should be machine translated or needs a human translation.
• *Quality - translation quality the file should meet.
• ImportTracking - let's you specify additional tracking fields that might be useful to track your assets.
• • Bob - book of business - usually the cost centre the asset belongs to.
  • Project - any internal project grouping.
  • SubProject - internal sub project grouping.
  • ContentType - type of file - e.g. Image, XLIFF, Video etc.
  • Wave - additional tracking field.

ImportExtended - extended metadata needed for Microsoft iCMS integration - if you don't use this integration, just leave it null.

• FileId - id of the iCMS source file.
• LocFileId - id of the iCMS target file.
• TopicId - topic id of the iCMS file.
• ChildrenLocFileID - children files of the file.
• IsManifest - specifies whether it's an article manifest or not.
• Tenant - iCMS tenant the file belongs to.

* - obligatory fields that must be provided for the import

All objects are available as a NuGet - Oddjob.Api.Models (supports .NET Core)