SDK-Handbuch › Integration › API Reference List › Translation Script Objects

Translation Script Objects

By default, the translation script runs in safe mode using the safe objects listed in this section.

Translation Script Overview

Insights into existing commit rules & behaviour

The following insights may help understanding the existing resource/ changeset commit behavior.

1. A resource/resource group cannot have multiple uncommitted changes in two separate change sets.
2. A resource/resource group cannot have multiple uncommitted changes over two separate dates.
3. Changing any of the following fields of a resource/resource group (from a particular effective date) cause the resource (and only that particular resource) to have uncommitted changes:
   • Effective
   • Resource Type
   • Service Components
   • Contract Parties
   • Any Custom Attributes
4. Changing any of the following fields of a resource/resource group (from a particular effective date) cause the resource and the related resource/resource groups to have uncommitted changes:
   • Resource Groups
   • Resource Members
5. When creating a new resource/resource group, a change set is passed. Two pieces of information are taken from this change set:
   1. The change set that the uncommitted change should be in, and
   2. The effective date from the resource is copied from the change set at the time of creating a new resource
   • Due to this point (b), a change set's effective date can be changed multiple times before the change set is committed.
   • We recommend calling Tools.CommitChangeSet or Tools.CommitResources after every 500-1000 changes, in order to keep the duration and size of the Tools.CommitChangeSet or Tools.CommitResources to a minimum.
   • Because Tools.CommitChangeSet (or Tools.CommitResources) impacts performance, we recommend not calling it after every change, but instead, after the last change.
   • It is possible to execute multiple (e.g., 500) of the following actions one after another, without requiring an intermediate commit change set or resources, since only the current resource being added/updated is effected, even if each of the actions refer to a different effective dates (assuming the same resource is not repeated).
   • Add a Resource (which is not within a Resource Group).
   • Add a Resource Group (which is not within a Resource Group, and which does not have Resource members).
   • Change resource effectiveness (ie Effective = Yes/No).
   • Change associated resource types / service components / contract parties.
   • Change resource custom attribute value(s).

Other miscellaneous resource rules

• A resource must be attached to at least one resource type.
• A resource cannot have a recursive relationship to itself, even though multiple resource groups.
• Updating resource general details is independent of change set and uncommitted changes.

Use of "Tools.CommitChangeSets" or "Tools.CommitResources"

Ideally "Tools.CommitChangeSets" or "Tools.CommitResources" should be called only after the change set has over 500 uncommitted resources, or at the end of the script.

Reasons to call "Tools.CommitChangeSets" other than this are before/after are:

• A resource is updated for the second time
• A call to Tools.AttachResourcesToResourceGroups
• A call to Tools.DetachResourcesToResourceGroups
• A call to Tools.AddResourceByMap - where the map includes non null value(s) for "ResourceGroups"
• A call to Tools.AddResourceGroupByMap - where the map includes non null value(s) for "ResourceGroups" or "Resources"
• A call to Tools.UpdateResourceByMap - where the map includes non null value(s) for "ResourceGroups"
• A call to Tools.UpdateResourceGroupByMap - where the map includes non null value(s) for "ResourceGroups" or "Resources"
• A call to Tools.AddResource - with non null / non empty ResourceGroups
• A call to Tools.AddResourceGroup - with non null / non empty Resources