Capsule Procedure vs Datamodel Procedure

Center of Excellence
Center of Excellence Employee
500 Likes 10 Comments First Anniversary Name Dropper
in Best Practices
1088x612_Article_Cover_Best-Practices.jpg

1. Abstract

While developers are facing procedure creation, they need to understand when it is appropriate to use data model procedures vs Capsule procedures.

2. Context

As developers, it is our responsibility to always keep the long-term maintainability of our solutions in mind. Procedures must be developed in a consistent and well-organized manner in order to allow other developers to step in and understand our work with minimal knowledge transfer time required. When creating a procedure, the 1st step is deciding whether we want a Capsule procedure or a Database procedure. This document provides specific guidance on when to use each type of procedure and how both can be used in concurrence to create a transparent and sustainable solution.

3. Content

3.1 When to use a Capsule procedure

Capsule procedures must be used for front-end actions or where user interaction is requiredsuch as screen interaction, saving data entry, refresh screen or navigation.

Examples:

  • Go to Capsule
  • Go to Screen
  • Show Message
  • Refresh Screen
  • Interactive Selection
  • Save Data Entry
  • Undo Data Entry
  • …

Other considerations on Capsule procedures are the following:

  • Capsule procedures are saved within the Capsule (not the Data Model).
  • Capsule procedures can only be invoked from Screens from within the same Capsule.
  • Capsule procedures cannot be invoked by the scheduler.
  • Capsule procedures can invoke procedures from multiple Data Models.
  • Capsule procedures cannot be transported across environments individually. The whole Capsule needs to be transferred.

3.2 When to use a Data Model procedure

Data Model procedures must be used for back-end actions where there is no user interaction or front-end action required such as dataflows and all the calculations, simple or complex, data loads, data exports, Data Model maintenance and backup, BEAM, predictive and clustering models.

Other considerations on Data Model procedures are the following:

  • Data Model procedures are saved within the Data Model (not the Capsule).
  • Data Model procedures can be invoked from different Capsules.
  • Data Model procedures can be invoked by the scheduler.
  • Data Model procedures can be transported across environments individually (seeTransporter tool). This is a big pro for Data Model maintenance and solution life cycle management.

3.3 How to combine Capsule and Data Model procedures

The distinction between Capsule and Data Model procedures highlights how they can be effectively combined to ensure the most suitable sequence is invoked for the given process. In some cases, it is necessary to trigger calculations, KPIs, or allocation procedures when saving data using Capsule procedures. To achieve this, it is recommended to create a Capsule procedure specifically for saving data and then call a Data Model procedure that handles data flows and performs calculations. This approach ensures the process is optimized and efficient.

image.png

Example: Capsule Procedure that calls Data Model Procedures

image.png

Example: Capsule Procedure that calls nested Data Model Procedures

image.png

Remarks:

  • Copy Current Select & Copy Back Current Select: the main procedure selection must be driven by the screen selection, the security, managed in the “Event-based trigger” or a mix of all of the previous. In the called or nested procedures, it may be necessary to have ad hoc selection to drive the specific calculation or sub-processes. When a procedure is called is good practice to flag the Copy Current Select option but never Copy back Current Select when the called procedure ends and we are back to the main process or to the event-based trigger. This is to avoid that the ad hoc selections, that are made for the specific subprocesses, are also affecting the active selection in all the other called procedures called.
  • Make sure that the Run on Current DB option is always flagged.
  • Identify procedures that are called from other procedures with the prefix CALL. This is important to evaluate any possible impact in case of any modifications in the called procedure.
  • Do not exceed nesting procedures. No more than three nested levels. This is to keep the process flow clear and the maintenance streamlined.

Tagged:

Comments

Categories