Import Process Model: Objects File Format

The spreadsheet used for the import of process model objects must have a reasonably specific, yet somewhat flexible, structure. The general-layout grid for objects to be imported is shown in below.

g

The values that are the most important are the codes in the green shaded cells. These values are located in the first row and the first column of a worksheet. Any extra information in the worksheet, extraneous to the import, can be displayed in a row or column as long as the row or column does not include a code. For example, Rows 6 through 11 and column G, are hidden but do not contain a code. These fields will be ignored, but they can be included in the spreadsheet for information purposes only. Colors and other formatting are irrelevant. For example, cells can be merged to make the hierarchical relationships between objects easier to see, but this makes no difference to the import, as the data is read from the first cell in a merged group of cells.

Specific Valid Object Codes and Values

Note: All of the codes and values listed below are not case-sensitive.

Languages:

The [language code] below, which is mandatory even if there is only one language active in the application, refers to the two-character code associated with one of the activated (not necessarily enabled) languages in the application. Currently the languages supported are the following:

Objects:

      ie., PS-EN for an English Process Set

The object codes above must be unique per language per worksheet (ie. there can be only one PR-ZH code, but of course there can also be a PR-EN code, in a given sheet). Also, they must be in the hierarchical order (ie. PS, PR, SP, TA, RE).  Although the fields and codes themselves are required, populating all the fields is not required for a successful import. For example, you may choose not to import any Resources, or any Tasks, or any Sub Processes, or any Process Sets. You may also choose to import only Process Sets, or only Processes, or only unassigned Tasks, or only unassigned Resources; however, you cannot import Subprocesses without a parent Process, because that situation cannot exist in the application.

For the first four objects, their Name is the only property to be imported. The value of each is validated against the validation rules established in the Property Definitions dialog. Any invalid values entered will still be imported to allow the import process to complete with the structure the user intended; however, the invalid values will be logged and reported, so the user can change them later if necessary. The log item includes the cell sheet, row, and column values, so that the item can be easily located.

Resources have five property codes:

      These property codes must be unique per worksheet.

Resource Type

The Resource Type property can (currently) only be one of the following:

Although these are not case-sensitive, they must be otherwise entered exactly as listed. Any rows with an invalid or blank resource type will be ignored.

Resource Category

The Resource Category property must be one of the available application categories, which are the following by default.  

Resource Subcategory

The Resource Sub Category property must be one of the available application categories, which are the following by default.

The value ”none” can also be entered for a resource category or subcategory to leave it non-categorized. Although these values are multilingual, they must be entered in English. If an invalid or blank category or subcategory are entered, or if the RC or RS codes are left off the spreadsheet altogether, the resource type’s default category or subcategory will be assigned to the imported resource.

To ensure that you are using the correct Resource Categories/ Resource Sub Categories, select Tools > System Options from the main menu, select the Task tab, and refer to the appropriate dialogs.

Resource Name Validation

In the same manner that the other objects’ names are validated, Resource Names and File Paths in the file are validated against validation rules set in the Property Definitions dialog. Invalid values entered are still imported, but they are logged and reported. If the RN or RF codes are left off the spreadsheet, the resource type’s default name or file path will be used for a specific resource. This means that technically, the only mandatory property column code for resources is the RT code (in addition to the RE-[language] row code).

The TR code indicates a column which contains a Task object and Resource object association. The cell which is at the intersection of these objects indicates the join. The value in this cell can be any value. In the above grid example it is a "●".

Multilingual Installations

For the first four object types (Process Set, Process, Sub Process, Task), only one language code per object is necessary, and object-language combinations must be unique (ie. only one ”PR-EN”) per sheet. Any other object-language code associations can be entered, in any order. That is, the language precedence as set in the application does not impact how the objects are imported.

Resources are somewhat different because there can be many resources on a sheet. Not all languages are required to be coded for a resource. A resource which has multilingual values is defined as a single object with multiple properties; however, only the Name (RN) and File Path (RF) are actually multilingual. A resource cannot be a different type in another language, or belong to another category or subcategory in another language. Therefore, in a resource "cluster”, only the first language’s Type, Category, and Sub Category are read. The other languages’ values for these properties are ignored. They can be left off the spreadsheet altogether. Also, if the Resource has a duplicate in the file, only the values for these properties of the first occurrence are read. The duplicate’s values are ignored. This means if a duplicate is entered, only one language value is necessary: the first language of the ”cluster”.

In addition, only Task-Resource associations related to the first language are imported, which means that a ”●” (or whatever other value) only has to be entered for the first item, but of course, Task-Resource associations related to all duplicates are imported.

The key thing about entering resources with multilingual values is that the cluster is defined as having at most one occurrence of a language.  A resource cannot have more than one English name, for example.  To simplify this concept, consider a two-language example.  When the sheet is read, if the language code of a resource is the same as the previous row, it is a new resource object.  If the language code is different, it is a property, in that language, of the same resource object.  To make sure that the language sequence in the cluster maintains this logic, it may be necessary to add blank rows for a language.  Of course, if a resource’s multilingual values are known beforehand, this strategy is unnecessary.

If the language repeats in the next row, the resource is a new object, but if the language changes, the value is a multilingual property of the previous object.  This same logic applies for an installation with three or more languages.  In this example, when imported with the application language set to English, the resources with only Thai language codes (ie. missing RE-EN codes) will display with the default English resource names (ex. "New TRACCable Resource”) while the resources with Thai values and blank English cells will display the Thai values, as per the language precedence rules.

It may be necessary and/or useful to repeat object values throughout the sheet or across the sheet to establish parent-child relationships.  Values are tested for duplication, and if an item is a duplicate, all child items are duplicated for that object.  The most obvious example of this occurs when you have a Task name repeated in the file.  Because of the uniqueness constraint on Task names, if a cell with a Task name C has Resources A and Y associated with it and another cell with the same Task name C has Resources B and Z associated with it, Task C will have all four Resources A, B, Y, and Z associated with it when the import is complete.  The fact that this duplication result occurs can be used advantageously, but also must be used carefully to ensure unexpected and undesired results are avoided.

Please note:  This duplication checking is that the check is only done for values in the first language with a non-blank value in the object ”cluster”.  In a typical situation this language is English, so in this situation only the English values are checked for duplication.

Logged Messages

When the import is completed, the text area at the top of the dialog reports three types of messages: Info, Warnings and Errors. The Info messages simply indicate duplicated values throughout the file, which are harmless and may or may not be a problem. This is useful when the end results in the Process Manager show unexpected relationships which can occur from duplicates, for example. The Warnings are shown when invalid categories and subcategories are found, because although these are not mission critical, the values are changed to defaults and therefore the user should be informed that they were changed. The Errors occur for a few different reasons, such as invalid or missing object codes, invalid property values, or database writing errors.

Additional Help: