Understanding the Defined Data Structures

A data structure is a particular way of storing and organizing data in a computer so that it can be used efficiently. A data structure represents real or abstract objects through use of data members-basic units of information which can be thought of as variables belonging to the object you wish to represent. An example is a person data structure, and its attributes could be data like hair color, shoe size, and date of birth. Each data structure has unique properties that make it well suited to give a certain view of the data.

Different kinds of data structures are suited to different kinds of applications. For example, Decisions offers a data structure that creates an entity (think “object” in traditional programming), such as an insurance policy entity, or a warehouse entity, or a store entity, and on that entity, you can perform actions like “cancel policy”, “add equipment,” or “perform inventory count.” But you would only find that useful if you were building a process that had an object like a policy, warehouse, or store. There is a data structure that creates a list of values. But again, you would only use that structure if a list of values is necessary. 

 Custom data structures are not required for processes in the Decisions platform, nor are they appropriate for every project.

Do I need a Custom Data Structure?

During planning, here are the kinds of questions that could determine whether to use a custom data structure:

1. Are your processes object-oriented (a noun) or functional (a verb)? That is, when you think about the overall picture of what you do, do you think first about the information that comes in and goes out, or do you think first about the processes that perform the transformation? If it’s the former, you’re probably going to wind up creating and using custom data structures. If it’s the latter, you’re probably going to focus more on building flows and reports to generate the same end results and leave out a custom data structure.
2. What are the reporting needs and do they involve more than process details? By default, Decisions automatically provides process-specific data, like who initiated it, the date, the state of the process (i.e. is it started, pending approval — 50% complete, completed), and current assignee, for example. If you wanted to include in a report “extra” data, like data captured in a form that was provided by a user, then a custom data structure could be used.
3. How often does the data change and do I need to keep a history of it? If you need snapshots of data, for example, you have a patient medical review process that has a status form for a condition that frequently changes, you’d likely want to save off that form’s information to a database that maintains that history for reporting.
4. Lastly, is there a lot of information? Because we recommend building processes in functional “blocks” (rather than in one big flow), that could mean passing in and out, and therefore mapping, a lot of individual variables. It is a lot easier to pass 1 custom data structure that contains all those variables. 

Answering “yes” to any of these will mean you want to use a custom data structure. Additionally, it could be that you decide to use a custom data structure because it’s a paradigm that the customer understands.

Consider the entire process when planning a data type. For example, you probably want to capture the initial request details. Then say much later in the process, if there is an approval step, you want to capture additional information such as an approval or rejection comment. Those should also be written to the complex data type. Think beyond the initial scope of the process when possible. Remember that we are just addressing data captured in a process (“process data”), not the data about the process (“flow data”) because flow data is meant to be handled separately.

Nature of Data to Consider

One way to help narrow down which custom data structure to use is to first determine whether the data is in motion or at rest.

“Data in motion” does not generally persist; the process is in control. The data is used and processed, but does not have a longer lifespan than the process. (You could save the data externally, for example, save the outcome; but generally this type of data does not need to be saved after the process ends.) Examples include a phone conversation or an approval process.

“Data at rest” lives on, even when the process is over. Consider it inactive data which is stored physically in any digital form (e.g. databases, data warehouses, spreadsheets, archives, tapes, off-site backups). This data is contextual. It doesn’t change, but things related to it do change. For example, a “student” can represent data at rest: he has gender, name, and shoe size. The student himself doesn’t change, rather things related to the student do change, such as buy car, get job, get driver’s license. A house is another example. You can paint it, pay for it, or put in new carpet, but it is still ultimately a house that persists. Other examples include an insurance policy or a ServiceDesk ticket.

The reason to consider these things and decide upon the nature of the data is because it will determine (1) whether you use a custom data structure, and (2) if so, what data structure you use to organize and store a process data.

Decisions Data Structures

Flow Execution Data Extension

This data structure is commonly used. Flow execution data extensions are custom data structures that enable your flow data to be extended to include process data. (Remember the difference – that flow data is automatically generated, and it is data about the flow, like who initiated, its current state). You can set up your process data so it is stored in the folder where flow data is normally stored. This enables you to do things like view data captured in a form on the process view page, or in a report that just uses the process folder as a data source, you would use this data structure. This data structure is recommended for data in motion.

Example: http://decdocs3x.wpengine.com/extending-process-data-with-flow-execution-data-extensions/

Folder Extension

A Folder Extension creates a folder that represents an entity. This folder can contain entities in addition to the object for which it is created. What helps me understand folder extension, is to think of it as the overall large container that will house smaller, individual entities. For example, a folder extension could be a store, or a restaurant, or a warehouse, and in it go objects like a package or a refrigerator, or a computer. The folder can contain process header information used to identify and differentiate the process, such as cost center, or a unique external reference number. The folder behaves just like any other portal folder, in that you can perform actions on each entity in the folder and use the folder in reporting. We’ll create a page for this folder to display a report showing details about the folder data. In our Decisions Training class scenario, we use Folder Extension folder to create an “Insurance Policy” Folder Extension entity. Its folder could have actions like “Renew Policy,” or “Cancel Policy” available that would perform those actions on that object. With Folder Extension data structure User creates a “blueprint” for creating specific Folders with specific properties in the Portal. These Folders could be visible in Portal tree which helps easily navigate to this type of entity.

Example of using Folder Extension: http://decdocs3x.wpengine.com/creating-and-using-folder-extension-data-structures-also-shows-folder-action-and-page-creation/

Entity
This data structure creates an object with unique methods. For example, you could create an “Employee” entity and its actions menu could have an entity action like “Get Employment History” that would perform the action on that entity. Folder Entities are added to existing folders (in other words, a folder is not automatically created for the object). Folder Entities contain the folder ID of the folder to which they belong. A table in the Decisions database is created for each Folder Entity structure defined. Objects created with this data structure cannot be visible in the Portal tree. Use this data structure when you want to create a persistent object and make available actions that are specific just to that object.

Example: http://decdocs3x.wpengine.com/creating-and-using-folder-entities/

Entity Extension

This data structure creates an object that extends existent type in decisions. For example we can extend native Decisions Document type with some additional meta data Entity Extension. Overall, Entity Extension data structure is like Entity data structure that is inherited from some Entity type.

Here is an example of using Entity Extension data structure: http://decdocs3x.wpengine.com/creating-entity-extension/

Defined Data Structure (Advanced)
This data structure is not commonly used, but available for advanced users. It can be used to extend an existing type, create a custom type to subclass, or create a subtype, custom .dll. It can be stored in a database. Not storing it in a database means the data won’t persist at all. This could be useful if you wanted to build a partial object and use it in a flow, but didn’t want these intermediary objects to be saved. This data structure doesn’t make actions against it available; it needs some other component to generate it or perform a method on it.

Example: http://decdocs3x.wpengine.com/ceating-defined-data-structures-advanced/

External Entity

External Entity is a data structure that helps to work with the objects that are not stored in Decisions database. With External Entity in Decisions it is possible to create Actions for External objects like: Search, Edit, Delete etc. Moreover, it is possible to Report on such objects. For instance, we may only have a connection to one folder on some FTP server. This folder may contain XML or JSON files with some data (like resume). With External Entity data structure in Decisions we may interact with these files and treat them as Decisions stored entities.

 Example of using External Entity data structure: http://decdocs3x.wpengine.com/external-entities/

Database Structure

This data structure is used to create an entity that is stored in the Decisions database in a table created just for the data structure. Its limitation is that it can’t perform actions on itself or others. It relies on other components to manipulate it, and other entities to contain it, and steps in flow to create it. This data structure is not visible in the Portal. We can Report on this structure. Also in the Configuration Extension folder for this data structure we can create Actions (using Flow Designer) to be used on this data structure in the Report. For this data structure System will generate steps like for the database table integration (create, delete, update, fetch, etc.).

Essentially, it is a way to create a database table.

How to create and use Database Structure: http://decdocs3x.wpengine.com/simple-database-structure/

 
Flow Structure
This data structure is used to create an entity that lives inside of a flow. It is simply a data structure that cannot be stored. Its limitation is that it can’t perform actions on itself or others. It relies on other components to manipulate it, and other entities to contain it. All you can do with it is create it and save it within a flow. This data structure should be only used as a Type for your Object. In other words, if we have an object like Person, instead of keeping all Person’s properties separate like: PersonName, PersonLastName; we can create a Flow Structure Person, that will have Name and Last Name properties and could be used in the Flow as Person.Name and Person.LastName. The key feature to remember is that this data structure is just a description of a type and the Object’s life cycle of this type is within a Flow. We cannot easily save these objects using Flow Structure.

Example: http://decdocs3x.wpengine.com/creating-simple-flow-structure/

Value List
This data structure builds an enumerated list of values. For example, an AllFiftyStates value list could contain Alaska, Alabama, etc., and be used to populate a drop-down list in a form. All data is string. If the data is going to remain completely static, it is not recommended to use this structure and simply build the static data into the process. If your data does change regularly, this might be useful.

How to create and use Value List: http://decdocs3x.wpengine.com/how-to-use-value-lists-in-a-flow/

Additional Resources

• Integrating Decisions with External Oracle Database