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 will let 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.

It is recommended to 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. As a result, the workload of the software engineers is reduced.

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 subsequently 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, such as the Software Programming Standards (SPS), Software Coding Standards (SCS), and performance guidelines. For more information on the rules applied by VSC, refer to Rules.

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 checked by VSC

VSC checks the following 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 make it possible to:
- 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 are:

A message called in a script, should not be expired.
A function 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 wether the software components match the rules. For each problem/conflict, a warning is generated.

Verification code

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

A verification code identifies the selection of checks that will be performed, and also 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 will be performed by VSC.

See the following figure for an example:

Sample verification code

Note

Multiple package combinations can be linked to the same verification code. However, 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 via the Verify Software Components (tlvsc3400m000) session, you must first specify the desired verification code, and subsequently select one of the package combinations that are linked to that verification code. As a result, 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 via the Verify Software Components (tlvsc3400m000) session. You specify verification code B61a and package combination B61asy05. As a result, all filters defined for verification code B61a (see the previous figure) will be 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, via a shortcut menu command. In these situations, VSC 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 figure.

Verification filter

Each verification code is linked to one or more verification filters, which define the checks that will be 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.

Example

VSC uses the verification filters that are displayed in the previous figure. As a result of this:

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 the following 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.

Warnings generated by VSC

Each warning has various attributes, such as:

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, refer to the online help of the Warnings (tlvsc3500m000) session.

Example

The table below 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 wrong label used : 'Page no.' should be 'ttgen.page'

You can handle the generated warnings via the Infor ERP LN Application Studio or via the Warnings (tlvsc3500m000) session. For more information, refer to To handle warnings.

Menu structure

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

The sessions are grouped in the following menus:

End Users. Contains sessions to verify software components and to view, print and handle the generated warnings.
Administrators. Contains the following 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, refer to 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.