# Assistant

## Key Features

The basic components to create an assistant are

- dialogue forms
- business application logic (implemented with LogiView)

The assistant is based on a application logic. It is defined in the mask Assistant Definition containing the single dialog steps like dialog step number, predecessor number, description and the function used at the mask.

Masks are defined with the form generator of DataView. The business application logic of an assistant is implemented with LogiView. The assistant toolbox combines these tools and adds two more components:

- the assistant definition where the single steps of an assistant are defined
- a set of userexits that are used to work with the dialogue forms

Each dialog step is identified by a dialog step number and a reference. Userexits and LogiView decision tables/procedures called are defined in the mask definition with triggers.

Userexit documentation.

### Naming conventions for the Assistant

For the names of the dialogue forms, the sub-lists and the LogiView procedures please observe the following naming conventions:

- Define a unique abbreviation for each assistant you create, if possible a three letter code (e.g. ECR for an assistant to create a new work request).
- Define an abbreviation for each step of the assistant. This abbreviation should be a three letter code and must be unique in the scope of this assistant (e.g. STA for the start dialogue form).

#### Dialog form and sub-lists

- For the name of a dialogue form combine ASS, the name of the assistants' abbreviation and the abbreviation of the step, all separated with a dash '-'. Always put a significant prefix that identifies your company in front of the name (e.g. SMP-ASS-ECR-STA).

- For the name of a sub-list there are no strict rules, but it is a good idea to describe the type of data that is contained in the sub-list. The name EDB-ASS-USR-NAM-SLI for example defines, that it is a list with user names. If the sub-list is a source list, its postfix should be SLIS, if it is a target list the postfix should be SLIT.

#### LogiView Procedures

- Create one logic model for each assistant. Combine the name from the significant prefix that identifies your company and the assistants' code (e.g. SMP_ECR).
- Complete the name of a LogiView procedure that you use to open a dialogue form from the assistants' code, a dash '-', the steps' code and the postfix Opn (e.g. ECR_STAOpn).

### Dialog form

| Although you define a dialogue form in the same way as other forms (such as the item or project form), there are some rules you should keep in mind:

Dialogue forms may consist of a main form and optional sub-lists too. Especially for the main form it is possible to use the form generator of DataView to define the layout.

### Rules for the Main Form

Although you define a dialogue form in the same way as other forms (such as the item or project form), there are some rules you should keep in mind:

- For technical reasons the field T_DLG_BOX.EDB_ID has to be defined as an invisible field of the form (length 1, width 3, position number e.g. 900).
- To be able to output a textual description please add the calculate field TEXT to the form.
- All fields of a dialogue form (except for T_DLG_BOX.EDB_ID) have to be calculate fields, therefore dialogue forms have no connection to the database (so you can not refresh its contents or directly store its contents into the database).
- The pre-mask userexit xform_call_prm has to be defined for a dialogue form. One of the tasks of this userexit is to add a set of buttons (such as < Previous, Next > and Cancel) on the lower right corner unless specified differently (see parameters of userexit). Remember this when you define the layout of a dialogue form.
- While it is possible to define field select menus (or radio button menus), it is not possible to define a select-/no select- or edit-(button-)menu for a dialogue form (but you can for sub-lists).
- Since there is no database transaction, the pre- and post-action userexits are not executed.
- Use the post-mask userexit to check the consistency of the complete dialogue form and to link your business application logic to the dialogue form.
- A dialogue form is opened with the userexit xform_call_dlg. See option /TEXT to set the textual description for field TEXT.

### Rules for Sub-Lists

A dialogue form may contain one or more sub-lists. Sub-lists may be used to display a number of values. A common way for sub-lists is to have two of them, one as a source and the other as a target list. The user then can select any number of records from the source list and move them to the target list.
To open a dialogue form with one or more sub-lists, the userexit xform_call_dlg has to be called with the option /SELECT. This option takes the name of the entity plus the name of the sub-list as an argument. Several sub lists can be separated by commas.

These are the rules for sub-lists in a dialogue form:

- Sub-lists can be defined for any entity and therefor can have a database connection too.
- Do not use the pre-mask userexit xform_call_prm. Instead you may use the standard userexit wdh_upd_lis to refresh the contents of a sub-list with database access.
- The pre- and post-action userexit is executed as usual.

For the combination of source and target lists there are additional rules:

- The post-mask userexit of the target sub-list must be xform_sav_rec_pom.
- Define a select menu for source and target sub-list to move records between these two lists. The userexit xform_cpy_rec has to be used for this purpose.

####