Validation pipeline
Grasp the general concepts, set up and working of the Validation pipeline with reference to Entities.
Last updated
Grasp the general concepts, set up and working of the Validation pipeline with reference to Entities.
Last updated
This section explains Validation pipelines and their usage with Langstack entities. By the end of this section, you will be able to understand fundamentals and hands-on applications of the Validation pipeline.
The Validation pipeline section consists of templates to create a series of checks. These checks can be performed on the data before being stored in a target entity.
A Validation pipeline can act as an independent unit usable in multiple Langstack applications without interfering with the logic of the Langstack application using it.
The validation pipeline can be edited without changing the Langstack applications associated with it. For example, suppose a Validation “Username_Acc_customers_validation” has a target entity “Username_Acc_customers”. In this case, the Validation rules can be updated without any impact on the target entity schema or the data within or any changes to the Langstack application that is using it.
One Validation pipeline can have one target entity configured. In the image below, the Validation “UserName_Acc_customers_validation” has one target entity “UserName_Acc_customers”.
A Validation pipeline can be executed through a dedicated API gateway. This option is available to the API.
Other Langstack application templates working with an entity, e.g. ETL pipeline or Process, can configure the Validation pipeline in the “Target Entities” tab if a target entity is selected.
Multiple Validation pipelines can be created for the same entity. For example, in banking operations, loan evaluation is different between students and non-students, in such a case, a different validation can be made for students through one API gateway and another API gateway for non students. While the same API is used for both API gateways, the validation steps are different depending on the customer's profile for the loan type. The validations may be defined as follows:
“UserName_Acc_customers_validation”: For a customer to qualify for a student loan, required details include Name, Social Security Number, Guardian’s Name, Account Number, College Reference. Validation 1 is set for the students API gateway.
UserName_Acc_newcustomers_validation” For a customer to qualify for a house mortgage, required details include Name, Social Security Number, Account Number, Annual Salary. Validation 2 is set for non-students.
Target entities in Langstack applications can be linked to one Validation pipeline, however, the user can choose in the API>Target Entities tab not to invoke the linked Validation pipeline.
To view the shared variables for this Validation pipeline, go to Variables. Two (2) variables are defined automatically on the creation of this validation:
Variable Name: “Source_UserName_Acc_customers”, Data Type: “UserName_Acc_customers” The variable name is automatically defined by the convention {Source_(target_entity_name)} and the data type is the entity itself. This variable contains the information to be validated and added to the entity as a source. For example, the API application sends the information of a record to the Validation pipeline, and that record sent to the Validation pipeline becomes the source.
Variable Name: “Response”, Data Type: “JXPResponse” This variable contains the response to be sent to the Action that attempted the creation or updating the Entity record, This response is in terms of success or failure of the Validation result.
To define the Actions, go to the “Code” tab of the Validation pipeline. On creating a new Validation pipeline, the system automatically creates all relevant Actions and their descriptions for all functions.
In the On Initialize function, a sequence of actions is already defined, which is executed when the validation is to be initialized. The Response object (which is of type JXPResponse) is initialized with successful response details. (This means that if the validation did not encounter invalid data during validation, it will respond with success.) The On Initialize function looks as per the image below.
The “On Validation step success” function is empty.
The “On Validation step fail” function is automatically configured to set the response status as “failed”.
The “On Error” function is automatically configured to set the response status as “failed”.
The “On Exit” function is automatically configured to send the Response.
When the Code>On Initialize function is executed, then the Validation steps function is executed. Steps in Validation are similar to Action boxes in API and other templates.
The Validation pipeline consists of a sequence of Validation Steps. To create a Validation Step, click the [+ Step] button in the Validation steps function.
A Validation Step in a Validation pipeline is similar to an “Action box”. A Step has a description field and three (3) tabs: Criteria, Code, and Variables.
Criteria tab: Users need to define a criteria in the Step. For each Step, at least one Criteria bar must exist in the Criteria tab to determine which section is to be executed in the Code tab.
Code tab: The sequence of executing the functions is as follows:
On Initialize function: the actions defined here are executed when the Step is initialized and before evaluating the criteria found in the Criteria tab and after all the variables defined in the step are initialized.
On Validation step success function: the actions defined in this section are executed when the criteria in the Step is evaluated true.
On Validation step fail function: the actions defined in this section are executed when the criteria in the Step is evaluated false.
On Error function: the actions defined in this section are executed when an error is encountered during the execution of On Initialize, On Validation step success or On Validation step fail, e.g. when mandatory information is invalid.
Variables: the variables defined in the Step>Code tab are initialized before any action or evaluation of the criteria is performed.
When any Langstack application that associates a Validation pipeline to a Target Entity and attempts to create or update an Entity record in it, the data of the Entity record is passed to the Validation pipeline and becomes the data source for the Validation pipeline. This data is stored in the form of an Entity variable type and is defined in the shared variables with the name Source_{Entity type name}.
To exit Validation Steps, use the Exit validation Action which can exit with either true or false.
If the Validation pipeline returns false, the create or Update Entity record operation will not be performed.
If the Validation pipeline returns true, this indicates a successful Validation pipeline status. Any changes to values of the entity record fields in the Validation pipeline will be included in the updated or created record. The image below shows effects of the Validation Pipeline result on the entity record.
