Selection supports

Support code

This field is used to assign an identifying code to a selection support. This identifier should not exceed 15 characters.

Target

This field is used to associate the selection support to the target and as a consequence make it available for use.

The Type field is used to enter one of the four type of selection support. This is one of the values in local menu 2965.

The Description field is used to enter a description for the selection support.

Description

This optional field is used to enter a quick descriptive text to inform the user either on the nature of the support itself or on the different benefits expected when using this support.

Processing

This field only concerns the supports of the Processing type. Provided the user has not clicked on the Type field and selected Processing, the Processing field remains non qualified. This field gives the name of the process associated with the selection support if it exists. All the processes associated with the selection supports have a name with the pre-fix "ZSSP" followed by a chrono number. These are therefore considered to be like custom/specific processings.

Each type requires a different use of the tool.

"All records" type support

This support is the most simple of the selection supports.

In addition, the user never has to worry about its creation because this is managed automatically by the system during the creation of a new target.

The user can however modify the Nameand the Description of these supports.

No component or processing needs to be defined for this support type. Thus, all its functionalities are inactive.

During use of this support by a target, it generates a population containing all the records in the target table.

"First level link" support type

This support is used to define the inter-table joins with the target table in the indexed fields database. The use of limited joins for indexed fields guarantees a high level of performance during the execution of a target.

On the other hand, this limitation reduces the spectrum of standard inter-table association possibilities. These possibilities are directly dependent on the index description defined in the X3 table dictionary.

Nevertheless, the selection support management function is used to define a greater number of new selection supports. These supports can be carried out on the database indexes, standard as well as specific/custom.

In this way, even if a critical index for a given sales activity is absent in the standard X3 dictionary, it is possible to define a new custom/specific index that will serve as a foundation in the construction of a new first level support.

The principal limitation of this type of support rests with its capacity to only associate tables that have DIRECT relations with the target. For example, the sales returns table (SRETURN) can be the object of a new custom/specific index SRHA for the BPCORD field.
In this way, a new first level support on all the sales returns can be constructed. This makes it possible to see a direct link between a return and a customer.

On the other hand, the return lines table (SRETURND) does not recognize the BPCORD field in its definition. Thus, there is only an indirect connection between the SRETURND table and the BPARTNER table. This relation passes via the SRETURN table. In this situation, it would not be possible to integrate the SRETURND table in a first level support.

Thus, the choice between the different type of supports is an essential step in the definition of the target.

Once this choice is carried out, it is necessary to carry out the construction of a first level support :

Level

Within the framework of a first level support, this field is automatically loaded with a value that is always 1. In fact, the target is always at level 0. This support only authorizes direct relations with the target and thus is level1. As a consequence, it is not possible to enter a value not equal to 1.

Table

This field is used to enter the table that will be linked with the target. The user is aided in this by an associated selection list or via a tunnel to X3 table management object.

Key

This field is used to indicate the field in the linked table that contains the value corresponding to the primary key of the target. The user can select this field from the list of fields that compose the linked table.

For example, in the case of an association of the Appointments table (BAPPOINT) with the BP target, the field containing the name of the visited BP is APTCMP. Thus, it is this field that must be entered in the "Key" column.

Parent table

Concerning the first level support, the parent level is always known by the system. This information is therefore always assigned by default with the target table code.

Parent key

Concerning the first level support, the parent level is always known by the system. This information is therefore always assigned by default with the name of the field representing the primary key in the target table.

Index

When a table is linked to a target, it implies that the user has previously made sure to have an index available allowing the linking to be carried out.

If this index is a single component, the system automatically takes on the checking of the "Index" and "Key components" fields. In fact, it has available all the necessary information in this case.

On the other hand, if the index is multi-component, the user is invited to indicate the index to be used to carry out the join. The latter case is aided by the use of a selection list containing all the available indexes in the table to be linked.

Filter or Key components

This field is used in a different way from a syntax point of view according to whether the user is defining a first level support or a grouping support.

In the example of a first level support, it is necessary to define the values of the different components of the index previously specified.

The number of values entered must absolutely be equal to the number of key components in the index. It is not possible to only use the first or second part of an index.

Key component entry syntax rules:

• Each key component must be separated by a semicolon.
• Each alphanumeric value must be between inverted commas.
• Although not mandatory, but in order to avoid all risk of conflict in variable names, it is strongly advised that each field name be preceded by its standard class abbreviation. For the fields in the tables, the class abbreviation is formulated as follows:

[F: followed by the table abbreviation code (three letters) in the X3 dictionary].

For example, for the BPADDRESS table: [F :BPA]

Remember the setup rules:

The definition of a first level support falls under certain rules recalled below;

• A linked table in this type of support cannot be defined with a level not equal to 1.
• A single linked table cannot be used several times in the same support with different link characteristics.
• It is not possible to build a link with the target passing by a partial sub-group of components for an index. All the components of an index must have a corresponding value in their link expression.

"Table grouping" support type

This support is used to define a tree structure or hierarchical network of inter-table relations all linked to the same target. This support type only must be used where it proves difficult or impossible to use a first level support.

Different to a first level support, this support type is used to define the links between tables in a non-indexed field database.. In addition, the links are not carried out only with a target but potentially, with any other table sharing a common characteristics.

This way, it is possible when starting from an isolated table in the X3 dictionary, to move up table after table up to a target.

As a consequence, this support type extends in an important way the spectrum of target possibilities that can be carried out.

Construction of a Table group support: in the "Chair" example

A support can be used to find all the business partners that have ordered a chair.

The definition of the target is as follows:

In this case, the selection support carries the essential search intelligence to make it possible to find the business partner from a product record.

The semantic delivered by the selection support for the Product criterion is: "Ordered products". The support must therefore lead to the BP table by passing via the sales orders.

The path proposed is the following:

From a product record, it is necessary to go back up the order lines. From an order line, it is necessary to pass up to the order. From an order, it is necessary to pass to the BP.

The grid below shows the route to achieve this:

From the ITMMASTER table at the lowest level it is necessary that the system moves up to the order line table SORDERQ. From here, it is necessary to indicate the field in the parent table (SORDERQ) that contains the value "Chair" (Chair being the product code. ITMREF field). In SORDERQ, this is also a field named ITMREF.

Then, from the order lines table, it is necessary to indicate to the system which field in the parent table contains the order code. In both tables, this field is called SOHNUM.

Finally, from the sales order table, the user indicates to the system which field in the target table contains the BP code. In the BP table it is the BPRNUM field. In the sales order table, it is the BPCORD field.

From this the system can determine which BP has ordered a chair.

This type of navigation structure can be used infinitely with all the tables within the constraint that the necessary connections between the tables exist.

For this, here are a few additional explanations on the construction rules for the grouping support type.

Level

This field is used to indicate the level of a table within the inter-table link structure.

• Level 0 corresponds to the target.
• Level 1 corresponds with a table directly linked to the target.
• Level 2 corresponds to a table linked to a level 1 table
  Etc...

Table

This field is used to include a new table within the link structure. The user is aided in this by an associated selection list or via a tunnel to X3 table management object.

Key

This field is used to indicate the field in the new inserted table that contains the corresponding value to the equivalent field in the parent table. The user can select this field from the list of fields that compose the table.

Parent table

The user is invited to indicate here the superior level table name in the link structure. The user is aided in this by a selection list containing all the tables at the immediate superior level.

Parent key

This field is used to identify the field in the parent table that contains the value corresponding to the equivalent field in the lower level table. The user can select this field from the list of fields that compose the table.

Index

This field does not have a role within the framework of a grouping support. It is as a consequence deactivated.

Filter or Key components

The field to field associations are easy to define and necessary to the links to a single component.

Nevertheless, some links require addition information to be correctly established.

The Address table (BPADDRESS) is a good example. This contains a BPANUM field containing the entity code for which the address is defined. The constructed link is as follows:

The problem rests with the fact that the BPANUM field can contain either a BP code or a Company code or even a Site code. Additional information is required to discriminate more precisely the relationship between BPADDRESS and BPARTNER. This information is stored in the BPATYP field. If the user wants to work only in the address sub-group relative to the BPs, it is necessary to add an additional filter:

The entry of the additional filter is under the control of certain syntax rules:

• Each logical expression must be separated by an operator in the following form:

• Each alphanumeric value must be between inverted commas.
• Although not mandatory, but in order to avoid all risk of conflict in variable names, it is strongly advised to proceed each field name by its standard class abbreviation. For the fields in the tables, the class abbreviation is formulated as follows:

[F: followed by the table abbreviation code (three letters) in the X3 dictionary].

For example, for the BPADDRESS table: [F :BPA]

Remember the setup rules:

The definition of the grouping support is made under certain rules:

• The definition of an inter-table link structure is always carried out from the top to the bottom. This means that the first level entered is 1, followed by level 2 then 3, etc.
• A single table cannot be used several times in the same support.
   This way, if a target requires the combination of a search on the ordered and invoiced products at the same time, two different selection criteria must be used together.

"Process" support type

This type of support is used to facilitate the editing and execution of an application code designed to generate a population of a given target within the framework of a target.

This support type should only be used when it is difficult or impossible to run either a first level support or a table grouping support.

To define this support type, it is sufficient to specify its type as Processing and to confirm its creation.

Defining the support type as Processing results in the deactivation of the support component entry grid but the activation on the other hand of the Functions - Process definition menu.

To start the processing creation, the user must click on the Functions – Process definition menu.

Once the processing is generated it can be opened and modified either from the selection support or from the Development - Process dictionary - Processes menu.

The selection support takes control of the creation of the processing skeleton where the different objectives are:

• Allowing a process to be called by the target function via a label and a structure of standardized setups.
• To carry out the recurring procedures for all processes of this type.
• To isolate in the subroutines, the parts of the codes that are normally constant, but which can be modified.
• To offer the possibility to the programmer in extreme cases, to modify all the elements comprising the program in order to resolve the more complex and unforeseen events.

The processing skeleton is composed of the different sections described below:

• BEGIN: This section is used to declare the work variables and to clean the population storage file resulting from a targeting.
  This section is enclosed in a sub-routine. This signifies that it is not generally likely to be modified.
• User section designed to open the tables: This section takes control of the opening of the target table. The programmer is then invited to open the additional tables necessary to the execution of their target.
• User search loop:This section is left to the programmer who can intervene to improve the intelligence of the search.
• SETDATA: This section is used in the transactional management of the records of the search result. It also takes control of the allocation of discriminating information necessary later in the target management
  This section is enclosed in a subroutine. This signifies that it is not generally likely to be modified.
• Section designed to be specified in the primary key of the target:This section is used by the programmer to modify the primary key defined by the system for the target. This is generally correct by default.
• WRITEDATA: This section is used in the physical record of a population record in the database.. The transactional management as well as the error management are assured.
  This section is enclosed in a subroutine. This signifies that it is not generally likely to be modified.
• TRANSACT: This management protects the optimized behavior of the transactional management proposed by default in the processing.
  This section is enclosed in a subroutine. This signifies that it is not generally likely to be modified.

The processing end controls the deactivation of any filters set on the target table.

Summary of the qualities of each type of support

In order to understand better the cases and the appropriate selection support type, the grid below displays the qualities for each of the different types listed. There only remains to decide between them according to the target constraints.