Objects
This grid displays the objects included in the build. Only published objects from published applications are allowed to be chosen.
However, when selecting precedents or dependents, published objects from unpublished applications can be chosen.
By clicking the 'Select Objects' button, a panel opens where objects can be searched, filtered, and selected to be included in the build.
•Every object has a checkbox.
•The check next to the title allows selecting all objects.
•Selecting at least one object enables the “Include” button.
When “Include” is clicked, a message appears prompting verification of precedents and dependents. If confirmed, the objects are added to the build and the “Select Precedents” and “Select Dependents” buttons are enabled.
Selection of Precedents and Dependents
The build offers assistance to identify precedents and dependents according to the objects Included. Once at least one object has been selected, the “Select Precedents” and “Select Dependents” buttons are displayed, allowing these objects to be added to the build and included in the package.
The build can be performed without including preceding or dependent objects, for example, when it is certain that they already exist in the target environment.
Is it necessary to include precedents in the build?
•No, if the precedent is exactly the same in the target environment.
•Yes, if the precedent does not exist in the target environment.
•Yes, if the precedent exists and is different in the target environment, and if the changes made to the precedent need to be carried over to the target environment.
The verification of precedents can be performed as many times as necessary, until no pending precedents remain to be included. This implies that precedents of precedents can be included recursively, until the list of unincluded precedents is empty.
When analyzing required precedents, it is common to find precedents that belong to another application, such as the global application. This can occur when an object modeled for one application is unintentionally assigned to another. In these cases, it is possible to correct the assignment so that all objects corresponding to an application are correctly grouped within it.
Clicking the “Select Precedents” button opens a panel where the precedents to include can be searched, filtered, and selected. Clicking on Include opens a confirmation message. If confirmed, the selected precedents are added to the objects grid of the build.
Is it necessary to include dependents in the build?
•It is not necessary to include dependents if the application does not exist in the target environment.
•Dependents must be included if the application already exists in the target environment and any of the selected objects have at least one of the following changes:
•In an entity: deletion of a field, or changes to the application, class name, identifier, or data type of a field.
•In a rule: deletion of a parameter, or changes to the application, class name, or data type of a parameter.
•In a process: deleting an entity relation, or changing the application or class name.
The verification of dependents can be performed as many times as necessary, until no pending dependents remain to be included. This allows including dependents of dependents recursively, until the list of excluded dependents is empty.
Clicking on the “Select Dependents” button opens a panel where the dependents to include can be searched, filtered, and selected. Clicking on “Include” opens a confirmation message. If confirmed, the selected dependents are added to the objects grid of the build.
In summary, it is likely that precedents will need to be included in a build, whereas including dependents is uncommon, since the conditions that justify it are rarely met.
Key Note:
It is essential to carefully evaluate whether it is really necessary to include all the precedents and dependents, or only some of them. Including unnecessary objects can result in larger packages than required, affecting both build and installation times and costs. Therefore, it is recommended to incorporate only those objects whose function is clearly understood and whose inclusion is justified, avoiding adding elements only 'just in case'.
Objects Excluded from Build
Some objects are excluded from application builds because they are an essential part of the target environment and must be configured directly there, such as test or production.
Deyel neither proposes them as precedents or dependents nor allows adding them to the object list or the entity data list.
Excluded items:
•Users, organizational units and agents:
They must be previously configured in the target environment for the installation to be successful. Otherwise, the installation will fail and be rejected.
•Adapters
Deyel allows exporting adapters directly from the modeler, but only the following properties are exported: identifier, name, descriptive name, and description.
Other configuration properties (such as server, database, job, user, password, etc.) are not exported and must be manually configured in the target environment.
•Job positions:
They are not exportable between environments and require manual configuration in the target environment.
If a job position is not defined in the target environment, the installation will be successful but incomplete, as a part that was modeled in the development environment will be missing.
Partially included objects:
•Roles:
Deyel includes the role only with its identifier, application, name, descriptive name and description.
Actors, coordinators, and role permissions are not exported between environments.
The installation will be successful, but for the application to function properly, role configuration must be completed in the target environment.
Build a Complete Application
To build a complete application, starting from the selection of objects, the following steps must be followed:
•Filter by the desired application.
•Scroll down to the bottom of the grid.
•Select all objects.
•Check the number of selected objects.
•Click the “Include” button.
