VSC overview

VSC (Verify Software Components) is used to perform a quality check on the software components, which are developed or changed in LN.

You can use VSC to:

  • Check whether software development is done according to the LN coding and programming standards.
  • Search for inconsistency in the tools dictionary.
  • Search for suspicious constructions.
  • Search for constructions the compiler lets through. For example:
    • (Dynamic) function implementation.
    • A message code is used in a script or library, but the message is expired or not present.

You can run VSC manually. VSC can also start automatically each time a software component is checked in.

We recommend that you use VSC on a regular basis during the development stage of the LN software products. In this way runtime errors, performance issues, and missing or expired labels, messages, and questions can be solved in an earlier phase. Therefore, the workload of the software engineers is reduced.

This diagram shows Verify Software Components (VSC)

Verify Software Components (VSC)

Based on the specified checks that are carried out in VSC, a list of warnings is generated to be handled. Per warning you can decide to accept the warning, or to solve the problem. If you accept a warning, the warning is removed from the "to handle" list. To solve the problem, you must edit the software component and then run VSC again.

Some errors can block the check-in process. If a blocking error occurs, you must accept the corresponding warning before you can continue the check-in of the involved software component. If you do not or cannot accept the warning, you must solve the problem and run VSC again, before you can check-in the component.

To perform quality checks, VSC applies various rules, which are based on the official LN design principles. For example, Software Programming Standards (SPS), Software Coding Standards (SCS), and performance guidelines.

Note: The rules in the VSC software are built according to the specifications in the rule database. This is a database that the LN development department uses to store information about existing and future rules.

Components that are checked by VSC

VSC checks these software components:

  • Messages
  • Questions
  • Sessions
  • Domains
  • Tables
  • Menus
  • Forms
  • Scripts (all types)
  • Reports
Note: 

During the verification of software components such as sessions, forms and reports, VSC automatically checks the corresponding labels.

VSC does not check “includes” and “help texts”.

Rules

To perform quality checks, VSC applies various rules that are based on:

  • The LN Software Coding Standards (SCS) - a set of standards that define how each software component type must be coded. For example: the coding standard for dynamic sessions is pp mmm s f xx o y cc. where:
    • pp - package code
    • mmm - module code
    • s - submodule code
    • f - function code
    • xx - sequence number
    • o - type of process
    • y - session sequence number; if more than one session is present for the same main table, this sequence number can be used to define the different sessions, starting with 0
    • cc - customization type
  • The LN Software Programming Standards (SPS) - a set of standards that define how engineers must write scripts and libraries. These standards provide these options:
    • Share good programming practices
    • Provide standard programming solutions and style
    • Manage complexity
    • Write code that is easier to understand, especially for other developers
  • The LN Performance Guide - a set of guidelines for optimizing the performance of the LN software.
  • Practice
  • Dynamic tests

Some examples of rules:

  • A message called in a script, should not be expired.
  • A function that is used in a form command, must exist in the session's UI script.
  • A DALHOOKERROR must be followed by a dal.set.error.message().
  • A business method called in a UI script, must exist in the DAL.
  • A query that performs an update must have a 'with retry' clause.
  • The number of parameters in a message call must match the number of parameters in the message description.
  • A question must have a default answer.
  • The length of the session description label in a form command must fit on a button.
  • Field specific buttons in a form must have bind type 'field'.

VSC checks whether the software components match the rules. For each problem/conflict, a warning is generated.

Verification code

The warnings that are generated by VSC are logged 'under' a certain verification code.

A verification code identifies the selection of checks that are performed, and determines the package combinations whose components you can check.

Each verification code is linked to:

  • One or more package combinations.
  • One or more verification filters. These filters define the checks that are performed by VSC.

This diagram shows an example:

Sample verification code
Note: Multiple package combinations can be linked to the same verification code, but each package combination can be linked to only one verification code.

When you run VSC, components of a single package combination are checked. When you run VSC through the Verify Software Components (tlvsc3400m000) session, you must first specify the desired verification code. Then select one of the package combinations that are linked to that verification code. VSC checks the components in the selected package combination, using the checks defined in the filters that are linked to the selected verification code.

Example

You run VSC through the Verify Software Components (tlvsc3400m000) session. You specify verification code B61a and package combination B61asy05. Therefore, all filters defined for verification code B61a,see the previous diagram, are used to verify software components in package combination B61asy05.

Depending on the verification code properties and the verification filter properties, VSC can start automatically when a software engineer checks in a component. At any stage in the development process, an engineer can also start VSC manually, through a shortcut menu command. VSC then verifies the component using the checks that are defined in the verification filters of the verification code to which the engineer's package combinations is linked.

Example

A software engineer, who is linked to package combination B61asy05, checks in a software component. VSC starts automatically.

Package combination B61asy05 is linked to verification code B61a. Therefore VSC checks the component, using the checks defined in the verification filters of B61a. See the previous diagram.

Verification filter

Each verification code is linked to one or more verification filters, which define the checks that are performed by VSC.

Usually a verification code is linked to one generic verification filter, and one or more specific verification filters.

Generic verification filter

The generic filter defines the checks that are executed to verify all software components in all packages. Depending on the filter settings, the checks in the generic filter can generate two types of warnings:

  • "Filtered to Handle" warnings. You must handle these warnings immediately. You must either solve or accept these filtered warnings.
  • "Non-filtered" warnings that you do not have to handle immediately.
Note: The generic filter that is generated during the installation of VSC generates only "Filtered to Handle" warnings.

Specific verification filters

Specific filters are used to reduce the number of "FiItered to Handle" warnings for a specific package, module or VRC. Each specific filter is derived from the generic filter, and therefore executes exactly the same checks as the generic filter. In a specific filter, you can indicate for each check whether you want to generate:

  • "FiItered to Handle" warnings that you must handle immediately, or
  • "Non-filtered" warnings that you do not have to handle immediately.
Note: You cannot disable checks, or add extra checks in a specific filter. If you select a check, which is not present in the generic filter, VSC ignores this check.

For Example: VSC uses the verification filters that are displayed in the previous diagram. These are the results:

  • For components in the tc package, the specific "tc" filter is used.
  • For components in the tdpur module, the specific "tdpur" filter is used.
  • And so on.

For each verification filter these properties are defined:

  • Priority Filter: determines the type of warnings ("FiItered to Handle" or "Non-filtered") that VSC must generate for the various error types, and whether these warnings can be accepted, or must be blocked.
  • Category Filter: determines the type of warnings ("FiItered to Handle" or "Non-filtered") that VSC must generate for the various types of checks ("General" checks, "Tools Consistency" checks , "Application Logic" checks, and so on).
  • Per component type: the checks that must be performed. For example: for forms, you can perform checks on standard options, specific options, buttons, various form field options, and so on. For tables, you can perform checks on table fields, indices, reference fields, messages, and so on.
Note: You can enable one or more source analyze codes for a verification filter.

Source Analyze Codes perform user-defined checks on scripts such as UI scripts, DLLs and DALs. Each Source Analyze Code is linked to a search pattern that consists of start expressions, end expressions and search expressions. For more information, refer to Source Analyze Codes.

Warnings

VSC generates warnings as a result of the checks that are defined for the verification filters. Depending on the filter settings, VSC generates:

  • "Filtered to Handle" warnings. You must handle these warnings immediately. You must either solve or accept these filtered warnings.
  • 'Non-filtered' warnings that you do not have to handle immediately.

This diagram shows the warnings generated by VSC:

Warnings generated by VSC

Each warning has various attributes:

  • Verification code.
  • Component Type.
  • Component, subcomponent and line number where the error occurs.
  • Priority: high, normal, suspicious, or low.
  • Category: General, Tools Consistency, Application Design, Application Logic, Standards, Text, Performance, Integration, Runtime, or Export.
  • Message ID and message text.

For more information, see the online help of the Warnings (tlvsc3500m000) session.

Example

This table shows 2 sample warnings.

Component Type Script Report
Package tt tt
Module adv adv
Component 2461 343001001
Sub Comp. group.1:init.group: Page No.
Line No. 117  
Priority Normal Suspicious
Category Application Logic Export
MsID 5003 152
Message db functions are not allowed anymore => Replace by query or queries Label not found or incorrect label used : 'Page no.' should be 'ttgen.page'

You can handle the generated warnings through the LN Studio or through the Warnings (tlvsc3500m000) session. For more information, see To handle warnings.

Menu structure

The VSC sessions are located under the menu path on the LN server. Select Tools > Application Development > Utilities > Verify Software Components.

The sessions are grouped in these menus:

  • End Users. Contains sessions to verify software components and to view, print and handle the generated warnings.
  • Administrators. Contains these sub menus:
    • Verification Codes. Contains sessions to configure VSC.
    • Warnings. Contains sessions to copy, move, or delete the generated warnings.
    • Import/Export. Contains sessions to transfer VSC data to another development environment.
    • Miscellaneous. contains miscellaneous administrative sessions.

For details on these sessions, see the session help.

Note: 
  • The sessions in the Verification Codes, Warnings and Import/Export menus are password protected. Each time you start one of these sessions, VSC prompts you for the VSC password. The application administrator can change this password in the Change Password VSC (tlvsc0291s000) session.
  • The sessions in the End Users and Miscellaneous menus are not password protected.