Packages

Packages are the Node modules capable of grouping features into consistent chunks, much like Sage X3 Modules do.

X3 Services packages are defined in the Packages function (GESAPACK) located in Development > Data and parameters > API > Packages.

A one-to-one relationship between Sage X3 Modules and Sage X3 Services packages does not exist.

The structure of Node packages allows for dependencies but does not allow for circular references, or a chain of dependencies that closes the loop on itself.

X3 Services packages include main packages and linking packages that act as a “transition” between main packages and their dependencies, or as a group of shared resources.

Packages function

In the GESAPACK function, you can create the standard Sage packages and the custom packages created by Partners and Customers.

• Package: The code of the package and the primary key in the Sage X3 table. It is mandatory.
• Owner: This identifies the owner of the package. It is mandatory and the owner code must start with a letter as any other character is forbidden. It is used in the repository structure to differentiate different sources. For example, Sage packages cannot be modified by non-Sage developers.
• Package name: Automatically populated based on the Owner and Package code. It is mandatory and can be amended but it must follow the naming convention. It must begin with an “@” and have a “/” between owner name and package code. Part of the package name will be used to build the files in the JavaScript repository.
• A valid package name must respect the following convention: @xxx/yyy. “xxx” represents the package owner and “yyy” the package name.
• Partner packages:
• If the GraphQL schema is created with the package name, the following naming rule must be strictly respected to avoid collisions in root fields of the schema: @xxx/xxxyyy or @xxx/xxx-yyy. “xxx” represents the packages owner and “yyy” the package name.
• Active checkbox: Defines whether a package is active or not. A package can be deactivated even if the module it is linked to is active. It is optional. When a package is not active, it is generated but it will not be included in the GraphQL schema. That means the package can’t be used in the application.
• Module: All packages must be attached to an Sage X3 module. It is mandatory.
• Activity code: Used to attach a main activity code to the package and extract patches. It is optional. If the activity code is disabled, packages linked to it are not generated.
• Type dropdown list
• Shared package: Refers to the Sage X3 Common Data module. Shared packages are organized by typology of data that contains reusable codes and can be used across multiple application packages. When creating a shared package in X3, the code generator defines the package metadata in the package’s package.json file.
• Application package: Expected to be fully independent. This means no dependencies would exist between packages.
• Linking package checkbox
• Editable only for Applicative package.
• Left unchecked if the package is a main applicative package. This refers to a set of properties or libraries that can be grouped together. By default, the main package definition is like the definition of modules in X3.
• Checked if this package is a linking package. This refers to a package that contains properties or libraries used to link a package to another. Such packages are required when developers need to add a property on a node managed in another package. The property will be declared in the linking package as a node extension of the main node. The link between two packages works both ways.
• Note: Linking packages or shared packages can’t be linked. Only main applicative packages can be linked.
• For example, the Purchase order number (POHNUM) package is declared as a node extension of the Sales order node (SORDER) in the x3-purchasing-sales linking package.
• It is mandatory to follow such development rules to define fully independent packages and, for example, being able to disable the Sage X3 Purchasing package and all its properties, including its extensions in the Sage X3 Sales package.
• Besides, the x3-purchasing-sales linking package will be used to define the Sales Order Category (SOHCAT) present in PurchaseOrder mode.
• Note: When a main package is deactivated in the Package management function, the associated linking packages are automatically deactivated too. On the contrary, it remains possible to deactivate a linking package without deactivating the two associated main packages. This results in having the main applications packages activated, but without any link between them.
• Main package for module/activity code checkbox
• Used to declare a reference package for a module and an activity code.
• If checked, this package will be used as a reference by the API generator to create the Enums files.
• It remains possible to create multiple packages for a module, but only one can be defined as the reference.
• Link between: : Editable only if Linking package checkbox is checked.
• Select the two packages linked by the new package created. For example:
  
• Activity code: Used to link specific activity codes to a package. The standard activity codes do not require any setup in the package definition function. They will automatically be generated in the SYSTEM package if they are used in the API.
• Specific activity codes (starting with an X, Y or Z) must be linked to a package to be generated.
• As partners may have to manage a lot of activity codes, creating a dedicated Shared package is recommended to declare all the activity codes not directly related with their respective applicative packages.

Available standard packages

The following table shows standard Sage X3 packages and how they are organized and structured:

Standard packages are in the /application directory in Sage X3 Services and are in the node-modules/@sage directory in the Sage X3 Services Developer Studio.

Custom and add-on packages are generated in the /application/@[YourNameSpace] directory in the Sage X3 Services Developer Studio where [YourNameSpace] is the namespace you chose for your packages.