Packages

Packages bundle Business Objects (BOs) which belong together and define if and how BOs can interact with each other. Every BO resides in exactly one Package. By default, a BO is internal (private) to a Package. It can only be used in another Package if you declare it as Visible.

Packages are designed to:

• simplify the management and organization of large and complex solutions
• foster reuse across different solutions
• boost agile and parallel development for teams
• act as the high-level building blocks of a Solution.

Each Package has a set of properties which define how the Package interfaces with the overall solution. The most important types are:

1. Visible Business Objects can be used by other (dependent) Packages. The typical use case is functionality that is shared among multiple Packages, e.g. a Catalog with all the world's currencies, a Process for producing a PDF file, a Script Function that converts the current date and time into the desired time zones, or a Screen with a form for collecting address information.
2. Replaceable Business Objects can be substituted by Business Objects either from the same Package or another Package (these Business Objects must be defined as replacements). This allows you to change the behavior of a Package without making changes to the Business Objects contained in the Package. For example, you can replace a default Template Screen that comes with a Package with your own version, thereby customizing the look & feel of all Screens to match your preferred style. You could also replace the default Business Rules from a Package with your specific ones, or change the style and language of Documents. All this can be done without changing the Package itself.
3. Entry Points allow triggering a Package via a Business Object (Process, Screen, or Script function) using a callable URL. Access control rules are configurable.

Managing development teams also becomes easier with Packages: for each Package, you can define the developers who are allowed to modify the Package and its content, everyone else is limited to read-only access.

This behavior of Packages is controlled from two places:

1. Package Configuration, which defines how the Package functions within your Solution (e.g. which BOs of the Package are replaced and what access control checks are used when an Entry Point is called).
2. Package Properties, which define how a Package can be used by declaring properties such as Visible BOs, Entry Points, Replaceable BOs, and dependencies on other Packages.

Package Overview

The Package overview displays all Packages available within your instance in FNZ Studio Composition.

View the Package overview by selecting Solution Design > Packages in FNZ Studio Composition.

From this overview, perform the following actions:

• Use the top-level menu to:

  • Filter the Packages displayed in the Package overview. You can filter also by Package name (e.g., DataLogic) or version (e.g., 1.3.0).

  • Import/Export Packages

  • Create a new Package

    Note on Package IDs: Note that some Package IDs are reserved and cannot be used when creating a Package. Examples of reserved IDs are function namespaces (e.g. Time), Business Object types (e.g. Process), Platform Packages (e.g. Blob), Extensions (e.g. RelationshipDefinition), functions installed by Extensions (AzureAI) and so on. The system issues a warning in these cases.

• Work with an existing Package by:

  • Clicking on a Package to see the summary in the sidebar and access the Package configuration (via the Configure Package button).

  • Double-clicking on a Package to open it (or click on Open Package in the sidebar). This gives access to the Business Object library where you can build solutions as well as to the Properties and Maintenance tabs.

  • (only for Sealed Packages) Clicking on the Create Package Version button to create a new version.

    Tips:n

    • Select the star in the top left of a Package card to pin the Package to the top of the Package overview.
    • A black dot displayed before the version number of the Package indicates that the Package version has been modified since being created.

Configuration

Package Configuration

The Package Configuration comprises settings that are specific to how a Package behaves in the context of your specific solution. Changing the Package Configuration does not change the Package itself.

To access the configuration of a Package, click on the Package in the overview and select the Open Configuration button in the sidebar.

The Configure Package dialog consists of the following menus:

• Business Objects Replacements Select 'replacement' Business Objects to replace Business Objects which are defined as 'replaceable' in the Package properties. See Replacing an Object in a Package for more context.
• Entry Point Access Control Define who can access the Entry Points defined in the Package properties. By default, access is denied to all users (No One). Further options are: Anyone (includes anonymous users) or Custom (requires specifying the exact user(s), role(s), and group(s)).

Access Control for Entry Points which were part of the Package in an earlier version, but have been deleted since, are still available in the Deleted Entry Points section. You can modify these settings, as running Processes using the deleted Entry Points can still exist. See Calling an Entry Point for more context.

• Permissions Define who can modify the Package and who has read-only access. By default, all developers can modify all Packages.
• Web API Configuration Configure the Web API Business Objects that exist in your Package. Each Web API is configured individually. See the Web API article for details on this Business Object and its configuration. This section of the Configure Package dialog is not available if there are no Web API Business Objects in your Package.

Note: The Package configuration is auto-committed every time it is changed. Apart from this, its behavior resembles other Business Objects as a version filter is applied. This means that running Processes use the configuration settings that were valid when the Process was started. An exception applies to Access Control settings for Entry Points: they are not versioned to allow changing the settings even for old, long-running Processes.

Other Configuration Business Objects

When exporting/importing a Package, consider that the exported configurations include not only the Package Configuration illustrated in the section above, but also the following Configuration Business Objects:

• Overriding Translations - Exports the translations defined for the Package in the Translations tab.
• Business Data Storage Configuration - Exports the Database mapping information (table, column names and so on) for each Data Class mapped by the Business Data Storage (BDS).
• Data History Configuration - Exports the tracking settings created in the Data History for each Data Class.

Inside a Package

To enter a Package, double-click on it in the Package overview. Three tabs are available:

• Business Objects Access the Business Object library and build your functionality using Processes, Screens, and other Business Objects, and organize your Business Objects in Lists. See Business Objects for details.
• Properties Make settings specific to the Package (General, Entry Points, Package Dependencies) and the Business Objects contained within (Visible, Replaceable, Replacements). See Package Properties Tab for more details.
• Maintenance Perform actions such as creating versions, deleting the Package, importing and exporting individual Business Objects to/from the Package, moving Business Objects. See Package Maintenance Tab for more details.

Business Objects Tab

The Business Objects tab provides access to the Business Objects in your Package, allows you to create new Business Objects, and organize them using lists:

• In the left panel, select a Business Object type to display all Business Objects of that type in the main area. Select Business Object Types at the top of the panel to see all Business Objects available in the Package in the main area. You can filter the Business Objects which are displayed using the Filter field available on the right above the main area.

• In the main area, when you select an individual Business Object, the properties, dependencies, and the change log are displayed in the right panel. Double-click a Business Object to open it in its editor and configure it.

Context Menu Options Depending on if you right-click on a Business Object type in the left panel, or an individual Business Object in the main area, different context options are available:

• New BusinessObjectType - Creates a new Business Object of the according type.

• New Business Object - Displays a dialog allowing you to select the type of Business Object you want to create.

• Duplicate - Duplicates the selected Business Object. Enter a new unique ID to complete the duplication.

• Delete - Deletes the selected Business Object (deleted Business Objects are shown with struck-through text).

  See Deleting Business Objects for details.

• Undelete - Undeletes the selected Business Object. If a Business Objects was deleted and then committed, it is no longer visible in the Business Object Library, but can be restored if it was committed before being deleted.

  See Restoring Deleted and Committed Business Objects for details.

• Refactor ID - Allows changing the ID of a Business Object.

  See Business Objects: ID Refactoring for more details.

• Show Dependencies - Shows the Business Objects the selected Business Object uses and is used by.

• Validate - Opens a dialog displaying all validation issues for the selected Business Object.

• Metadata - Allows you to view, add, and delete metadata for the selected Business Object.

• Add List - Creates a new static List.

  See the section on Custom Lists below.

• Add Smart List - Creates a new Smart (dynamic) List.

  See the section on Custom Lists below.

• Commit Selected - Opens the Commit dialog listing only selected and uncommitted Business Object(s).

• Commit Mine - Opens the Commit dialog listing only uncommitted Business Object(s) for which you made the last change.

• Commit All - Opens the Commit dialog listing all of the uncommitted Business Object(s) in the Package.

  See Committing Business Objects for details on the all three Commit options.

• Import .awexport - Allows importing an AWEXPORT file.

• Import Any - Allows importing any type of file. The Platform suggests a Business Object Type to import to.

• Export - Opens the Export dialog allowing you to select the Business Objects and Custom Lists you want to export to an AWEXPORT file.

• Export Selected - Opens the Export dialog listing the selected Business Object(s) so you can export them to an AWEXPORT file.

  See Deployment: Business Object Import and Export for details on importing and exporting AWEXPORT files.

• Revert Selected - Allows you to revert to an earlier version of the selected Business Object.

  See Reverting to Earlier Versions for details.

• Show Versions - Displays the version history of the selected Business Object.

  See Getting an Overview of Versions for details.

• Compare Versions - Opens the Business Object Diff Viewer allowing you to compare two versions of a Business Object.

• Compare Business Objects - Opens the Business Object Diff Viewer allowing you to compare two different Business Objects of the same type. This option is only available when you select two Business Objects of the same type.

Custom Lists

'Custom Lists' are user-created groups of Business Objects. Users create and manage these lists. There are two different types of lists:

• Static Lists - Contain Business Objects which users add to them manually. To create a static List:
  • Right-click anywhere in the left panel and select Add List.
  • Name the list and press Return.
  • Add Business Objects to the List using drag and drop.
• Smart Lists - Contain Business Objects which are added automatically, according to criteria defined in the Edit Smart List dialog. To create a new Smart List:

  • Right-click anywhere in the left panel and select Add Smart List.

  • Name the list and press Return.

  • Right-click the new Smart List and select Edit Smart List.

  • In the opened dialog, define the criteria according to which Business Objects will be added to the list. Use the wizard for many different types of pre-defined criteria like Accessed, Committed, Created etc., or you can select Specify Script to use a custom script (see below).

    Tips:

    • Organize Custom Lists into hierarchies by dragging a list on top of another to nest it.
    • Under Default Lists, you will find a number of pre-defined Smart Lists covering the most common cases, like collecting uncommitted or recently used Business Objects.

Using Custom Script in Smart Lists To define a Script in a Smart List: select Specify Script in the Edit Smart List dialog and click on the "c" icon to the right of the Script field.

Each Business Object is passed to the Script as the variable $bo. The Script evaluates all Business Objects contained in the Package. If the Script returns true, the Business Object is shown in the list, if it returns false, the Business Object is not shown. Two examples follow below.

This Script shows all Business Objects with unsatisfied outgoing dependencies in a Smart List:

 // get all outgoing dependencies
  Indexed Any  $dependencies := OUTGOINGDEPENDENCIES($bo.getType(),$bo.getId());
     // for every dependency ...
     Any $reference;
  ForEach $reference In $dependencies Do
       // try to get target object
       Any $object := CONTEXT().getReferenceService().getObject($reference);
     // if object not found ...
      If $object == null Then
          // unsatisified dependency
           Return true;
        End
     End
     // no unsatisified dependencies found
     Return false;

This Script shows all Business Objects which are Screens and have the word "template" in their ID, Name, or Description in a Smart List:

    // check whether "Template" is part of the name,
   // id or description
    Boolean $name_matches_template;
     $name_matches_template := MATCH(LOWERCASE($bo.getDisplayName()),'template');
      Boolean $id_matches_template;
     $id_matches_template := MATCH(LOWERCASE($bo.getId()),'template');
     Boolean $desc_matches_template;
     $desc_matches_template := MATCH(LOWERCASE($bo.getDescription()),'template');
     Boolean $is_template_part;
     $is_template_part := OR($name_matches_template,$id_matches_template,$desc_matches_template);
    //
    // now check to see whether this object is a Screen
      Boolean $is_screen;
  $is_screen := EQUAL($bo.getType(), 'Screen');
     //
    // show it if it's both a Template element and a Screen
     Return($is_template_part && $is_screen);

A note on testing the Business Object type: Testing $bo.getType() against 'Screen' is pretty obvious, but for other Business Objects, e.g. those whose names consist of more than one word, the exact term to use is not so clear. See the below table to see how to test for different Business Object types.

Properties Tab

Package Properties are divided into two parts.

1. Package section, containing the following options:

   • General- Change the description, vendor, and image associated with the Package.

   • Entry Points - Define the Entry Points to your Package and select the Business Objects the Entry Points invoke.

   • Package Dependencies - Define which Packages your Package is dependent on. Your Package can use the Visible Business Objects available in Packages defined as dependent.

   • Compare Versions of Properties - Opens a diff viewer that compares the general properties of a Package (e.g., ID, Description, Vendor and so on) between two different versions (the Package versions to be compared are selected from the related dropdown lists).

     Notes:

     • All Packages depend on the Base Package by default and can use all objects Base contains. In contrast, Base cannot use any visible objects available in other Packages by default. See The Base Package section for details.
     • You cannot define a dependency on an explicit version of a Package.
     • Dependencies are not checked and enforced at runtime (design-time check only).

2. Business Objects section, containing the following options:

   • Visible - Define which Business Objects in your Package are visible. Other Packages (with a dependency on your Package) can use these Business Objects.
   • Replaceable - Define which Business Objects in your Package can be replaced.
   • Replacement - Define which Business Objects can be used as replacements. A Business Object defined as a replacement can substitute Replaceable Business Objects in other Packages.

The following sections provide an overview of the main options.

Entry Points

Entry Points allow making an application available to others via a URL. For example, if you create an application in PackageA, you design ProcessA to be the starting point of using the application.

Follow these steps to create an Entry Point:

1. In the properties of PackageA, go to the Entry Points menu, add an Entry Point with the Entry Point ID=application, and select ProcessA as the Business Object.
2. To allow users to start your solution via the application Entry Point, go to the configuration of PackageA, and select the Entry Point Access Control menu. Find application in the list and grant access to users as required by your solution (by default, access is denied to all users).
3. Users defined in (2) can now access the Process via the URL: /entrypoint/PackageA/application provided in the Entry Points and Entry Point Access Control menus (a HEAD filter is applied automatically). The URL is assembled according to the syntax:/entrypoint/[PackageID]/[EntryPointID]

Note: The URL is case sensitive.

4. To ensure that this Entry Point is active for Workspace users and can be accessed via {BASE_URL}/entrypoint/[PackageID]/[EntryPointID], ProcessA must be committed and contained in a Package version. This is because Entry Points redirect in the following way: They go to the latest Package version (NOT the last modified version) and then, in that Package version, use the latest committed version of the Business Object that is referenced by an Entry Point. Be aware of the following three cases:
   • If no Package version exists (only version 0.0.0 with modifications exists), the first part of the redirect fails, even if the appropriate committed Business Object exists.
   • If a Package version exists, but does not contain a committed version of the Business Object referenced by the Entry Point, the second part of the redirect fails.
   • If a Package version exists, and the Business Object referenced by the Entry Point was committed multiple times before the Package version was created, the Entry Point uses the latest committed version.

Further information on Entry Points:

• Only Processes, Screens, and Script Functions can be accessed via Entry Points.
• If no Entry Point is defined for a Process, Screen, or Script Function, the user must be authenticated and a member of the role Administrator to be able to access it via a URL.
• When an Entry Point is defined for a Process, Screen, or Script Function, the Access Control settings also apply to FNZ Studio Composition users who want to start the Business Object in FNZ Studio Composition. Example: If you assign a Process to an Entry Point, FNZ Studio Composition users can only start the Process in FNZ Studio Composition (e.g. using the Start Process option) if they have been granted access to the Entry Point.
• Entry Points are not available in the Base Package. Use Access Policies instead.
• An Entry Point is labeled by the Entry Point ID, which in turn redirects to the defined Business Object. This means that if you change the Business Object defined for the Entry Point, the URL continues to work, simply redirecting to the newly defined Business Object.
• URL query parameters are supported.
• Entry Points support the HTTP method GET.
• You can define Entry Points in the configuration property nm.window.start, e.g.: nm.window.start = REDIRECT:{ CONTEXT_PATH }{/internal}/entrypoint/[PackageID]/[EntryPointID]. Doing so serves as a "global" redirect for users accessing a solution via a fully qualified domain name (FQDN) without a specified Entry Point. If you do so, ensure appropriate access rights are set for the Entry Point in the Package Configuration. Adding /internal to the path requires the user to be logged in (the login page is shown if the user is not logged in).

Visible

The Visible option allows using a Business Object available, e.g., in PackageA in a solution built, e.g., in PackageB.

Follow these steps to make Business Objects Visible:

1. The Business Object you want to use in PackageB must be defined as 'Visible' in PackageA. Go to the properties of PackageA , and select this Business Object in the Make Business Objects Visible dropdown. As an alternative, you can also select the Make Visible option from the context menu of any Business Object from the library
2. PackageB must declare that it wants to use a Business Object from another Package. Go to the Package Dependencies menu in the properties of PackageB. Define PackageA as a dependency. You can now use all Visible BOs from PackageA in your PackageB.

Calling a Visible Business Object from Another Package

If you are currently inside of PackageB and you want to call the Script Function ScriptA, which is located in a different Package, PackageA. The Script Function is visible and PackageB has a dependency defined on PackageA.

To reference the Script, use the fully qualified Business Object ID: PackageA:ScriptA

Guidelines:

• In general, always use the fully qualified BO ID to reference Business Objects, according to this pattern: [PackageId]:[BusinessObjectId]
• An exception to this rule applies to Business Objects from the Base Package, which do not use a Package ID: Do not call them with a Package prefix like Base:String but directly, like String or Integer (think of the Base Package as an artificial Package ID).

Maintenance Tab

Create Package Versions

You can create versions of Packages to be able to import and export them across different systems and reuse them in other Solutions. Additionally, the list of versions allows you to understand how a Package was modified since the last version and provide improved control over installed versions. Creating a Version is facilitated by a step-by-step wizard available after clicking on the Create Version button.

Versioning of Packages is an explicit action controlled by developers. This means you decide:

• When to create a version
• What numbering to apply within the semantic versioning syntax enforced by the Platform: Major.Minor.Patch-tag, e.g. 1.0.0-beta. The tag (-beta) can be defined freely or omitted from the version number.
• What information to specify in the Version Notes.

A Package Version contains:

• Package properties:

  • General information (Package ID, name, description, vendor, logo)
  • Entry Points, Package Dependencies
  • Visible BOs, Replaceable BOs, Replacement BOs

• All committed Business Objects (only amodified Package version may contain Uncommitted Business Objects, see section below for details)

  Note: See Business Objects: Versioning for details on Business Object versions and committing them.

• Version details: Version notes (concatenated through all versions), version date, version number

• Configuration Business Objects, namely: Package Configuration, and other Configuration Business Objects, namely Overriding Translations, Business Data Storage, and Data History (see section below for details).

Creating a Package Version for Modified Configuration Business Objects

When a Package is unchanged, but any Configuration Business Objects get modified, you need to create a new Package version to include such changes. To perform this operation, the Platform supports you as follows:

• Unsealed Packages: A a banner suggests creating a new Package version and, when clicking Create Version, the system suggests a version number appended with '-conf' (e.g. 0.0.1-conf). You can change this version number.

• Read-only Packages: A banner suggests creating a new Package version and, when clicking Create Version, the system creates a version number appended with '-conf' (e.g. 0.0.1-conf). You can change the suffix, but not the version number.

• Sealed Packages: Click on the Create Package Version button available on the Package Overview page when selecting a Sealed Package.

Package Versions Created Automatically

In addition to explicitly created versions, there are two Package versions which are created automatically:

• The modified version is an implicit Version that gets created as soon as you modify a Package. The modified version contains all changes since the last, explicit Package Version was created, including uncommitted changes to Business Objects.
• Version 0.0.0, an empty baseline Version which is created automatically whenever you create a Package.

Compare Package Versions

This feature allows you to compare the content of two versions of the same Package. This functionality is especially useful during release and upgrade operations on Packages to inspect the changes in Package content across versions.

Consider that this does not include Configuration Business Objects.

1. Select the two Package versions to be compared from the dropdowns: Compare Version (allows selecting any Package version) and To (allows selecting any Package version previous to the one already selected). By default, the Compare Version dropdown contains the latest Package version, while the To dropdown contains the second latest Package version.

2. By clicking on Add Filter, you can apply one of the following filters: Type (Screen, Process, and so on), Business Object ID, or Operation (Changed, Deleted, New and so on).

3. Once filters are set, the table is populated with the list of Business Objects in the Package.

4. The Operation column contains the type of change occurred between the two Package versions. For Changed Business Objects, you can open the Business Object Compare Version tool to inspect the exact changes between the two versions. Note that, starting from FNZ Studio 2024, Package Properties (Package description, vendor, logo, and so on) can also be compared. This feature is also available through the Compare Versions of Properties option under the Properties tab.

5. You can download a detailed report in .CSV format by clicking the Full Report button. Note that no filters are applied. The report is also accessible through Script Function Package:CompareVersionsReport.

   Important: The check on Business Object change is based on the comparison of an internal ID (Copy Of UUID) that represents each Business Object in a Package version. Since such comparison is not directly based on the Business Object content, there are some situations where the internal ID was changed, but the content of the Business Object is the same. In these cases, the Business Object Compare Version tool shows no modifications for the selected Business Object, although reported as Changed.

Validate Package

Select the version to validate (Head or Latest Committed) and click on the Validate button to validate your Package. Validation allows you to monitor and improve the state of your Package at any time. Validation reports errors, warnings, and info messages with regards to dependencies, Business Object usage and visibility, and many other areas.

Delete Package

A wizard for deleting your Package, click on the Next button and follow the provided instructions.

Note: As always in the Platform, running Processes continue to work even if BOs or Packages are deleted (except when the Platform's versioning system is intentionally not applied).

The 'Business Objects' section contains the following menus:

Import and Export

Allows you to import and export selected Business Objects to/from the Package. Files containing selected Business Objects have the ending AWEXPORT. For Package import/export (AWDEPLOYMENT), see One-Click Deployment documentation.

Note: You can only import into a Package with exact same ID as the Package from which you exported. If no Package with this ID exists, create it before importing. After importing, you can move the imported Business Objects to a different Package as required.

Move Business Objects

A wizard that supports you in moving Business Objects from one Package to another. The wizard suggests how to adjust Package properties (Visibility, Dependencies) to maintain a working solution. To start the wizard for moving Business Objects, click on Start Moving Business Objects and follow the instructions.

Note: The Prevent moving of Business Objects which may affect running Processes check-box is selected by default. It filters out objects that can break running Processes if moved, like Integration Links and their direct, outgoing dependencies.

See Refactoring Existing Solutions to Packages for more details on moving Business Objects.

Migration Tools

The Migration Tools section contains the following menus:

• Styling A wizard that supports migrating from legacy styles to 'Style' Business Objects.

Importing and Exporting Packages

Export and import Packages to share them across different systems or reuse them in other Solutions. Files containing Packages have the ending AWDEPLOYMENT.

Starting from Appway 11, the One-Click Deployment feature provides a set of capabilities to improve the overall experience of importing and exporting Solutions across different environments. See all details on Package import/export in the related documentation

For the specific case of Package import, consider that a Package can also be imported automatically when starting the Platform:

1. Place AWDEPLOYMENT files containing the Packages and Package Configurations you want to import into the following folder in the Data Home: <Local file system>/data/packages.

2. The nm.packages.autodeployment.strategy configuration property allows determining the behavior of automatic Package deployment. It can be set to:

   • add: only new Packages, or Packages that were deleted on the target environment are imported
   • upgrade (default value): new Packages or Packages that were deleted on the target environment are imported; existing Packages are upgraded if they were not modified on the target environment; no downgrade is possible
   • replace: all Packages are imported, and existing Packages are overridden

3. At startup, the Platform imports all Packages and Package Configurations found in the packages folder. The AWDEPLOYMENT files containing the Packages are not deleted after importing.

   Note: Besides importing/exporting complete Packages, you can also import/export selected Business Objects contained in a Package (`AWEXPORT` files). See the Business Object Import/Export document for detailed information.

The Base Package

The Base Package is a default Package which is always available. The Base Package has the following unique characteristics:

• When migrating from a Platform version where the Packages functionality does not exist (< 7.0) to Appway 7.0 or higher, all Business Objects are placed in the Base Package.

• After a new installation, Base is the only Package available. It contains default Business Objects such as Primitive Types (String, Integer, Boolean etc.), Colors etc.

• Many default Business Objects are protected, including certain Primitive Types (e.g. String, Boolean, Date, User), Data Classes (e.g. Action, PdfRenderConfiguration), Styles and Style Values (e.g. Button, Text), Labels (e.g. validation.error.number), Fonts and Font Styles (e.g. courier_regular, courier_bold), and Format Patterns. Protected Business Objects cannot be deleted, refactored, or moved to another Package.

• The Base Package cannot be deleted.

• The Base Package cannot be versioned.

• Setting the Package Configuration and Properties is not supported for the Base Package. All Business Objects from the Base Package are Visible.

• The following Business Object types are only available in the Base Package: Access Policy, Language

  Note: Access Policies can only be used to govern access to Business Objects (Screens, Processes, Script Functions, Resource BOs) in the Base Package. n For access control in other Packages, use Entry Points instead (for Screens, Processes, and Script Functions). For information on access control for Resource BOs in other Packages, see Default Accessibility of Resource Business Objects via Url.

• All other Packages have an automatic dependency on the Base Package, which means that all Business Objects in the Base Package are visible to and can be used by all other Packages

• Business Objects contained in the Base Package cannot use Business Objects contained in other Packages.

  Note: This behavior can be changed by setting the `nm.packages.base.seesOtherPackages` configuration property to `true`. This allows Business Objects in the Base Package to use Visible Business Objects from other Packages. This is useful during migration, but it is not recommended as a permanent solution.

• Business Objects in the Base Package do not have a Package-related prefix added to their name. You can call them directly, without any prefix. For example, call String and not Base:String.

  Tip: Avoid creating new Business Objects in the Base Package, create a dedicated Package instead. The only scenario where you should have non-FNZ Studio Business Objects in the Base Package is when you are migrating from older (before 7.0) Platform versions.

Special Package Types

Style Packages

Style Packages provide a simple and fast way of setting consistent styling for a complete solution.

Style Package Basics

A Style Package is applied to a Screen using the Style Package property which is available in the View component, which is the root component of each Screen.

Note: Only Packages on which your current Package has declared a dependency can be selected as a Style Package. Set dependencies on the Package Properties tab, in the Package Dependencies section.

At runtime, the 'Style' Business Objects in the selected Style Package override the 'Style' Business Objects defined in the Screen, if the 'Style' Business Objects:

• Have the same short ID (meaning the ID without the Package prefix), and
• Apply to the same component type

The behavior in special cases is as follows:

• If a rendered Screen has one or more Screen Includes and the View components on those Screens also define Style Packages, only the first Style Package in the hierarchy of View components is applied, all others are ignored.

  Note: This means that you should not place any Screen Components that are visible to users before the first View component that has a Style Package set. Otherwise, these components are rendered using the original 'Style' Business Objects, not the ones contained in the Style Package.

• If the defined Style Package does not contain a 'Style' Business Object with the same ID and type, the 'Style' Business Object defined in the Screen is used.

  See Style Packages: Styling Applications and Working with Themes for more details on applying Style Packages in a solution.

Sealed Packages

A sealed Package is a restricted type of Package. As sealed Packages cannot be modified, they can be upgraded seamlessly. You can integrate a sealed Package into your Solution through its interface, for example you can use visible Business Objects, call Entry Points, and replace Business Objects.

Examples of sealed Packages include those delivered as part of Application Business Components.

Although you cannot modify a sealed Package, you can:

• Use a sealed Package in your Solutions
• Import a sealed Package to your system
• Update a sealed Package (import a newer version of the sealed Package)
• Delete or obliterate a sealed Package from your system
• Set the Package Configuration for a sealed Package

In FNZ Studio Composition, sealed Packages are clearly indicated by a label in the top right corner of the Package card (also displayed to the right of the Package name when you are inside a sealed Package).

Read-only vs Sealed Packages

Both read-only and sealed Packages cannot be modified. However, sealed Packages can be updated (a newer version imported), deleted, or obliterated, distinguishing them from read-only Packages, which cannot be updated, deleted or obliterated.

Package permissions (defining for which users a Package appears as read-only) can be set for a sealed Package, just like for any other Package, as sealing does not restrict access to the Package configuration.

In other words, the difference can be described as: Read-only permissions are specific to the developers of a Solution - helping to organize who can modify which Package - whereas sealed Packages cannot be modified on any Solution by any developer.

Platform Packages

Platform Packages contain different types of content you can use, e.g. the Data Classes used to enable the Business Object Reference functionality.

Platform Packages are marked by the following icon , and are installed automatically when starting FNZ Studio or when uploading and starting the related extensions for the first time. The Platform Packages installed with FNZ Studio are: Blob; Catalog; DataClass; DataRules; DocumentCategory; Format; Label; Package; Process; Resource; Rule; RuleSet; Screen. Examples of Platform Packages installed with extensions are AppTask, or DataGathering (other may be available depending on your extensions).

Platform Packages have the following characteristics:

• They are sealed (cannot be modified)
• They are not shown in the Package overview with other Packages
• To use the Business Objects contained in a Platform Package, you must declare a dependency from your current Package (Properties tab), with the exception of the Base Package, which has an implicit dependency on all Platform Packages.

Theme Packages

Theme Packages contain branding information (colors, sizes, and so on) which is used to customize Applications that are using App Tasks.

The Create New Package (System Design) in FNZ Studio Composition displays a Theme Package checkbox, which allows you to flag a new Package as a Theme Package. A Theme Package starts empty, and is filled through the Theme Editor. However, you can also create a Theme package in the Theme Editor directly, by opening the Developer Toolbar.