Namespace and Object Types

Docusnap allows you to create custom object nodes. This can be done in Docusnap Management by clicking on the Manage Objects button.

If you want to make custom extensions available in Docusnap for other users or environments, it is helpful to separate them thematically. A clear structure allows you to select individual customizations and export them independently of each other. The separation and structuring of different customizations can be implemented specifically using namespaces and ObjectTypeIDs.

Namespace

Namespaces can be used for all object nodes and serve to clearly assign them to a specific topic area, for example for certain projects, customer solutions, or feature extensions.

Typically, a new namespace is defined when creating a custom table or column, as this is often the starting point for user-defined extensions. However, if no custom table or view is needed, the namespace can also be specified directly when creating an object node.

An object node can either be created without a namespace or assigned to an existing namespace. It is important to note that subordinate nodes cannot have their own, different namespace. For subordinate nodes, only the namespace of the parent node or no namespace at all can be selected. Using a separate, different namespace at this level is not possible.

For exporting customizations, Docusnap offers the option to either export all extensions or specifically the contents of a particular namespace. If a specific namespace is selected, all associated elements as well as all customizations without a namespace will be exported.

ObjectTypeIDs

The ObjectTypeID serves as the unique identifier for each object node and forms the basis for the hierarchical structure within the object tree.

When a node is created, the next available value is automatically assigned based on the parent node.

For user-defined extensions, it may be useful to use a dedicated number range to separate customizings thematically or organizationally. To do this, the ObjectTypeID of the starting node is manually set to a freely chosen value, for example 2,000,000. All objects subsequently added within this structure will then receive consecutive IDs based on this starting value. Using higher object type IDs helps reduce the risk of conflicts with existing customizings.

If the ID of a node is changed afterwards, any existing subordinate nodes will remain unaffected. Their IDs will not be adjusted and will retain their originally assigned value.