The first step in configuring a context for your data is to define the context. Each context needs a starting point for filling the context with data. You then define item groups to contain the items of interest. This article describes how to configure this structure.

• Context
• AddParts
• ItemGroup

Prerequisites

• Familiar with the SystemWeaver meta model building blocks (e.g., Items, Parts and Attributes)
• Familiar with the SystemWeaver Explorer Interface and common operations
• Familiar with the SystemWeaver Script Language
• Familiar with Using the XML Editor
• An installation of the SystemWeaver Explorer client (swExplorer)
• Knowledge of XML (A good resource is w3schools' XML tutorials)
• Assignment of the SW Architect role in the server

Things to Consider

• Contexts must adhere to the meta model.
• Items within a context are seen as context items (TcontextItem) and not "ordinary" items which enables the use of the context functionality. In general, context items are treated as ordinary items. However, when using . or only a variable, they currently are not. A rule of thumb when working with context is to compare using Handle/AncestorHandle and using .Select(Name) in log. 

Context

The starting point can be the currently select item (referred to in the context definition as "main") and/or Parameters. The <Context> tag must be used to define a context. It can be defined anywhere in a configuration and is valid for the item for which it is defined. There are two attributes:

• name is the unique name of the context.
• ignoreVersions when set to "true" enables you to match on all versions of an item. The default is to match on exact version only. Optional.

After defining the starting point for a context, the context tree needs to be built using item groups containing items of interest. It is possible to group different item types and part types. To define the groupings, you can use <AddParts> and/or <ItemGroup>.

AddParts

<AddParts> will start from owner (main or parameter) of the part to be added, and result in creating a group (defobj), or in some cases, adding to an existing group. <AddParts> has a number of optional attributes. These are all described in detail in the application Help. Note that four of them are required: 

• Owner indicates the group that owns the parts to be added. Owner can be previously defined as defobj or "main" for the selected item. Main is a default keyword for the entry item. Note: If the report or view has any Parameters defined, there will automatically be contexts defined corresponding to each parameter using the name(s) of the parameter(s).
• sid is the SID of the part of interest.
• part defines a name for the parts to be added. This value is later used to traverse the context using, e.g., <ContextGoForward/> and <ContextGoBack/>.
• defobj defines a name for the group of items, that the parts are linked to/point to.

Example

<Report>
  <Context name="architectureTop">
    <AddParts owner="main" sid="3EFL" part="archToE2EList" defobj="E2EList"/>
    <AddParts owner="E2EList" sid="3PEN" part="E2EListToE2E" defobj="E2Es"/>
  </Context>
...
</Report>

Example Explanation

Using the Context visualizer, you can graphically visualize the context:

<AddParts owner="main" sid="3EFL" part="archToE2EList" defobj=”E2EList"/> 

Then, <AddParts owner="E2EList" sid="3PEN" part="E2EListToE2E" defobj="E2Es"/>

ItemGroup

The context can also be built using <ItemGroup> or a combination of <ItemGroup> and <AddParts>. ItemGroup creates an item group using a path expression that starts from the context (main or parameters). To find out more about how <ItemGroup> works, and how to combine its use with <AddParts>, see Using ItemGroup in Context. 

What's Next?

Learn how to use the defined item groups to retrieve the data.