Same fields, multiple scripts

Same Fields, Multiple Scripts

This design pattern describes options for simplifying a form where fields may be repeated in multiple scripts and what to avoid.

Often master data forms require multiple functions (search, create, and change, for example) within a single form. This may result in the same fields being repeated in each script for the same Master record.

Creating and maintaining forms that use the same fields in multiple scripts can be very cumbersome. In addition, the structure of the groups and fields can make it difficult to understand a form with duplicated fields and the maintenance even more difficult.

There are multiple ways to address this problem and reduce or eliminate the number of duplicated fields, when designing and planning a new form. However, below and in the following pages we provide general recommendations that can help, particularly if you already have a form built that includes duplicated fields.

Groups are defined as Microsoft defines them in InfoPath: an element in the data source that can contain fields and other groups. These groups are represented in both Microsoft InfoPath and Winshuttle Designer, and keeping them in sync is key to a working solution. Winshuttle Designer will automate groups and fields in InfoPath to make it easier to design a simple form, but when you have the same fields in multiple scripts it often requires some modification to the automated structure.

Benefits

Choosing and planning for a recommended option (see below) helps avoid pitfalls and makes form design and maintenance easier.
Reduce or eliminate duplicated fields.

Read before you begin

Tips: Avoid these 2 pitfalls:

Do not rename groups or fields that have been automatically generated by Winshuttle Designer.
Once Designer has generated a group and fields, you can not change it and must keep the name and structure that has been generated by Designer.
Note: It is possible to delete a field that has been automatically generated from Designer if that field is not used in any web service.
Do not move fields that have been automatically generated from Designer to different groups.
Winshuttle does not support this. There are known issues if fields from a web service are moved to a different group. This can corrupt the Solution file.
Note: It is possible to move fields not tied to a web service to a different group.

If you already have a solution built:

For small to medium sized forms, leave all existing fields in their original structure. For each duplicate, pick a field to use and then remap all scripts to the chosen field.
For large forms (or small-to-medium-sized forms experiencing performance issues), follow the instructions (above) for small to medium size forms. Make a backup of the file, and then delete any fields you are not using in the form.

If you are planning or designing a new solution:

There are 3 different recommended options if you are in the planning or design phase. Read below for a description of each option. Each of the following options has its own risks and benefits influenced by a variety of factors, such as:

The intended functionality of the form
The number of fields in a form
The developer’s knowledge level of SAP, InfoPath, and Winshuttle products
The developer’s personal preferences

Option 1: Use a common group for scripts with common fields

Use the same group name in Winshuttle Designer for all the scripts that contain commonly used fields.

However, this can be optional for Winshuttle Query scripts because they can have a more complex structure (repeating groups, elements, etc.) and the default naming scheme within the script can be confusing.

In general queries can be mapped to their own unique group if you prefer, and a recommended practice for someone new to Winshuttle Designer.

When mapping fields in Designer, be sure to use the option Use existing fields.

After all scripts have been mapped and the InfoPath Form has been auto-generated, a few fields will need to be manually added to the form.

For example, the log fields and validation fields will need to be different for each script—as well as any other fields as determined by the developer.

First manually add these fields to InfoPath then remap just these fields in Designer.

Pros

Option 1 reduces the overall number of fields in a form, which is especially useful for large forms. However, this method requires a good understanding of each SAP script because the structure of the script (i.e. which fields go with which script and which ones are inputs vs. outputs) is not obvious with this design. This option also uses the most automation between Winshuttle Designer and Microsoft InfoPath.

Cons

The developer is new to SAP or the T-codes used in a form. The layout of the form fields do not retain the SAP structure in InfoPath.
Rrepeating web services are used. Repeating web services need a unique Group assigned to them because of their complex structure. (For repeating web services Option 3 is recommended.)

See the following for additional information:

Manage field mappings, and Remapping Fields, under Workflow Design Notes
Manually adding a field under Form Design Notes

Option 2: Manually create groups, fields, and map

First, manually create the groups and fields in InfoPath. Then, in Winshuttle Designer manually map each script to each of these manual fields. The fields created within InfoPath will automatically show up in Designer.

Note: Do NOT use the Generate InfoPath Form button within Designer. Only do steps 1 to 4 in Workflow Design Notes  Manage field mappings section.

Pros

A few scripts are used, or a lot of fields are repeated in multiple scripts.
Forms are cleaner and easier to edit if/when changes occur with scripts.
The developer has more control over the organization of the fields.

Cons

It can take longer to build the initial form,
The form is less automated and does not use the mapping automation that helps make designing a form easier.
Not a good option for novice developers or someone new to Microsoft InfoPath or Winshuttle Designer.

See the following for additional information:

Naming Conventions Design Pattern (for recommendations on naming groups and fields).
Workflow Design Notes (Manage field mappings and Remapping fields),
Form Design Notes (Manually adding a field)

Option 3: Give each script a unique group name

When mapping, give each script a unique group name. Once you have created unique groups, you must decide whether or not to use different field names (and keep the fields in sync), or to pick one field name for each value.

Note: Do NOT use the Use existing fields option to ensure each web service's fields are auto-generated in InfoPath with unique field names.

Option 3 (General) Pros

Easiest to set up initially
Uses automation in Winshuttle Designer.
Best for when only a few fields are repeated in a form.

As part of this option you will also need to choose one of the following sub-options (each with its own advantages, disadvantages, and characteristics to achieve the desired results:

Use different fields names (and keep them in sync)
Select a field name for each field value.

See below for more information.

Option 3A: Use different field names and keep fields in sync

Recommendations:

Keep each script aligned with their given fields names from Winshuttle Transaction and Winshuttle Query.
Edit the field names in Winshuttle Transaction before importing them into Winshuttle Designer. This makes managing field names easier in the form.
Change the field names slightly for each script. For example, material description-read, material description-create, or material description-change. The auto-generation of fields in Designer and InfoPath will match the field names in Transaction or Query.
See also Script Design Notes (Change a field name in a Transaction script)

If you do not change the field names in Transaction so that they are unique for each script, clicking Generate InfoPath Form in Winshuttle Designer will map fields to the Transaction or Query-given name—even if multiple scripts have the same field name.

However, when duplicated fields are automatically generated in InfoPath, an underscore and number ia automatically added to the name—for example, material description_1, material description_2, etc.

This only occurs when you are not using the use existing fields option, the recommended method for implementing this option. After all fields are automatically generated in InfoPath, you need to remap them to the correct fields in Winshuttle Designer.

For this specific scenario the initial default for Winshuttle Designer and Microsoft InfoPath will not be in sync and fields will need to be remapped.

Once the field mappings are set correctly for Designer and InfoPath, then you need to keep the values of the different field names in sync. You can do this by either creating a default value, or by creating a rule.

You will need a default value or rule for each field value that is repeated in a script.

Default values: Using a default value prevents the user from overwriting or changing a field value.
Rules: Using rules allows the user to overwrite or change the field value if needed. This is the recommended option because most forms need to allow the user to modify the field.

Option 3A Pros

Preserves the original structure, which makes it easy to identify where fields are used in each script within the InfoPath structure.
Best when the developer has little SAP knowledge of the T-codes being used.

Option 3A Cons

Each duplicated field will need either a default value or rule created, which could take considerable time if many fields are duplicated.
More difficult to use if the developer is inexperienced with SAP or the T-codes used in the form. Consider Option 1, which has fewer steps and uses more automation.

Option 3B: Select a field name for each field value

Select one field name for a field value, and then use that name in all scripts, and then delete other fields that exist for the same value.

Example:

Use a field from Script A.
Delete the same field values in Script B and Script C (i.e. the fields ending in _1, _2, etc.).
Make sure each web service is using the correct field.
Make sure InfoPath and Designer field mappings are in sync.

Option 3B Pros

Reduces the number of fields

Option 3B Cons

Structure of the fields in InfoPath may be confusing because fields from one script (Script B) will be under the group for another (Script A).
Not efficient if multiple developers are involved or major changes are planned at a later date.
Research may be required to understand the InfoPath structure of fields because it will not be logical or match the SAP scripts.