Defining Model Nodes

In this step of the roadmap, you define which data provider forms the basis for the import of node metadata and the data extraction for connectors of this model. The data providers define the type of the data sources to be imported. You also create the nodes of the model, assign node names, and define properties for the node attributes.

In this step, the nodes are displayed as a list, without any hierarchical structure. You define the structure in the next step.

When defining nodes for a DataSource-based model, note the following:

Type of Data

Recommended Model Layout

Master data

The model generally contains a node for master data attributes and a node for texts. The nodes can be time-specific or time-independent. If there is no DataSource for texts or no DataSource for master data attributes, the model can only contain one node. If there is no DataSource for texts, but the DataSource for master data attributes contains text fields, the master data model can also only have one node.

The general guideline is that a model should only contain DataSources that relate to the same business object.

Example Example

Let us assume that the DataSources ZCOMP_CODE_ATTR, ZCOMP_CODE_TEXT, and ZCOMPANY_TEXT are available. The recommendations for the model layout are as follows:

Define a model ZCOMP_CODE containing the nodes ZCOMP_CODE_ATTR and ZCOMP_CODE_TEXT.
Define a model ZCOMPANY containing the node ZCOMPANY_TEXT.

End of the example.

Note Note

How you define the master data models affects the replication of data in the SAP HANA database or in BWA, since replication is executed at the model level (connector). This means that the nodes of a model are replicated together in the SAP HANA database or in BWA. If a model contains a node for master data attributes and a text node, this ensures the master data is as consistent as possible.

End of the note.

Transaction data

The model contains a single node for the transaction data DataSource.

Example Example

Let us assume that there are two semantically-linked DataSources, for example one for the header data of an order (2LIS_11_VAHDR) and one for the order items including the header information (2LIS_11_VAITM). In this case, each DataSource should be contained in a separate model.

End of the example.

Note Note

It may be necessary for search purposes to import the DataSource for the header data to the model for the items. In this case we recommend defining the model with two nodes: one node based on the DataSource that contains the header data and item data, and one node based on the DataSource for the header data.

End of the note.

Procedure

1. Select Data Provider for the Model

Under Metadata Provider Type, define the data providers from which you want to import data sources as node metadata into the model. The choices available are BW-DataSource, DDIC, and WCF BOL Data Provider.

Note Note

Note that all nodes of the model must use the same extraction technology. For this reason, you can only define the type of the metadata provider if there are not yet any nodes in the model.

End of the note.

2. Insert Node into Model

To create a node, choose Create Node.
Enter the name and description of the node.
To import a data source and its attributes into the model, enter the name of the data source for this node.
If you want to use a BW DataSource as a data source and import it into the model, an input help is available. For DDIC, you can enter table names, view names, and structure names as a data source (input help is not supported).

Note
When you import a DataSource, the system adopts the technical name and the description of the DataSource for the node name and the node description by default. The node name is cut off after 20 characters.

If a DataSource for master data attributes follows the naming convention <NAME>_ATTR and the associated text DataSource follows the naming convention <NAME>_TEXT, the system automatically imports both DataSources, if you choose the DataSource for master data attributes. In this case, the system automatically defines the DataSource for master data attributes as the root node.

End of the note.
Define whether or not the node is to be the root node by selecting the radio button in the Root column.
By default, the first node in the table is selected as the root node.

Note
If you select another node as the root node, it will appear at the top of the list the next time you return to this screen.

In the case of master data DataSources, the DataSource for master data attributes must be defined as a root node.

End of the note.

3. Define Properties of Node Attributes

Choose the node in question to edit its properties.
Change the attributes of the node in the Details: Attributes of Node '<node name>' area.
To select node attributes whose values you want to extract and index for this node, select the Select (select for node) column in the Details: Attributes of Node '<node name>' area. Only selected attributes are available for further modeling and can be used in searches or for operational data provisioning.
You may have to scroll down to find additional attributes. Once you select an attribute, it is automatically moved to the top of the list.

Note
You can use the content of binary files attached to the business objects (for example, documents) for the search. For this, the attribute must contain a URL that points to the document. To resolve pure URLs (without a destination) that, for example, point to documents in a document management system, the communication can take place only via HTTP without querying user and password.

End of the note.
Specify the properties of the selected node attributes. You can adapt the properties for a node attribute by using the following columns:
- Description:
  If necessary, you can add a description for a selected attribute or change an existing description.
  
  To access the description, simply click into the relevant entry in the column. Enter your description and use the tab key to leave the field.
  
  Note
  For DataSources, the descriptions of the node attributes are adopted from the DataSource (or from the extraction structure). We recommend making changes to the description of a node attribute only if the description in the DataSource and the description for analysis purposes should be different. Otherwise we recommend not changing the description of the attributes in nodes, if possible.
  
  End of the note.
- Key:
  Here you define which of the available attributes are key fields in the model. By default, the system adopts the selection of attributes as key fields. For DataSource-based nodes, for example, this means that if the Data Source contains key fields, the system suggests the corresponding node attributes as key fields of the node.
  
  On the one hand, key fields are relevant for foreign-key relationships if they model relationships (associations or compositions) between model nodes; on the other hand, they are relevant during data replication to the SAP HANA database or to BWA because the records for a node are overwritten according to the modeled key. Therefore, we recommend that you check and maintain the key fields carefully.
  Note
  If a DataSource does not have any key fields, the system defines the first node attribute in the attribute list as a key field.
  Note that if you want to use DataSources for operational data provisioning, the following rules apply to the definition of key fields:
  
  If the DataSource is language-specific, the LANGU-type field must be part of the key.
  If the DataSource is language-independent, the LANGU-type field must not be part of the key.
  If the DataSource is time-specific, the DATETO-type field must be part of the key and the DATEFROM-type field must not be part of the key.
  If the DataSource is time-independent, neither the DATETO-type field nor the DATEFROM-type field must be part of the key.
  The field that transfers the record mode (for example ROCANCEL or UPDMOD) must not be part of the key.
  End of the note.
- Cont. Text (attribute contains readable text):
  Here you define whether the attribute contains readable text. You also set this property for attributes that use a URL to point to attached documents.
  
  Define this property for fields of text DataSources that you want to use for operational data provisioning and that contain short, medium, or long texts. Check the suggestion made by the system and change it if necessary.
  
  Note
  If DataSources contain both master data attributes and texts, you can define the model so that a separate node, and therefore the operational data provider (ODP) for texts, are not necessary. To enable the master data ODP to also support texts, select Cont. Text for the text fields of the DataSource. In the Operational Data Provider step, you can then create an ODP for master data attributes, from which the texts can be read at runtime.
  
  End of the note.
- Conversion:
  Conversion of values with leading zeros so that the zeros are ignored during the search and removed for the output.
- Semantics:
  You can define the (business) meaning of the node attribute here.
  
  In particular, note the following for DataSources that you want to use for operational data provisioning:
  - Nodes in master data models contain a node attribute that is called the Representative Key Field of the node (or operational data provider). This attribute corresponds to the BW InfoObject that is represented by the node. Choose the Representative Key Field option for the attribute that has this function.
    
    Note
    If you do not define the representative key field here, this does not trigger an error in modeling, and the system attempts to determine the representative key field by evaluating the associations of the model. However, defining the representative key field explicitly has the following advantages:
    
    If a foreign-key dependency is defined across multiple fields, the representative key field is the one for which the association is joined. This fact becomes apparent when you define the representative key field explicitly.
    
    If the representative key field has to be derived by the system, this can lead to unexpected results. You can avoid this if you define the representative key field explicitly.
    
    End of the note.
    
    Example
    The node 0COSTCENTER “Cost Center” has the key fields KOKRS, KOSTL, and DATETO. In addition, an association is defined from 0COSTCENTER to 0CO_AREA (whose only key field is KOKRS) by way of an Equal join to KOKRS. Therefore:
    
    The representative key field for 0COSTCENTER is KOSTL.
    The representative key field for 0CO_AREA is KOKRS.
    If you have defined an ODP 0SEND_CCTR to represent the characteristic "Sending Cost Center", which references the node 0COSTCENTER, the representative key field for 0SEND_CCTR is also KOSTL.
    
    End of the example.
  - Choose the Valid From option or Valid To option for time key fields (such as DATEFROM/DATETO).
    Note that the time key fields must be of type DATS. The attribute with the semantic Valid To must be a key field of the DataSource.
  - The system suggests the Language Code option for selectable language key fields with data type LANG (such as LANGU). If the language key field in the DataSource is not flagged as selectable, the system does not suggest this option. in this case, you choose the Language Code option manually.
    Note that the language key fields must be of type LANG.
  - In the case of DataSource fields that are to be assigned to time characteristics (for example 0CALMONTH or 0FISCYEAR), choose a suitable option for the semantic (for example Calendar Year and Month or Fiscal Year). If the system makes a suggestion, check this and change it if necessary. During the TransientProvider runtime, the system maps these fields to the corresponding time characteristics and can thus provide the master data attributes and hierarchies.
  In the case of the search, note that if you choose the Language Code option, the search is then performed language-independently so that only results in the logon language are output.
- No Extraction: You can define here for the search whether or not the attribute is relevant for display and access but not for extraction.
  
  Example
  In the classification search, there is an non-indexed dummy field whose content TREX converts to seven or nine real attributes during searches.
  
  End of the example.
Furthermore, the following properties of the node attributes are displayed:
- Type: Specifies the type of the attribute.
- Name in Back End: Specifies the name of the attribute as used in the back-end system.
- Switched: Specifies whether or not a model with the Switch Assignment function has been activated using the SAP Switch Framework. This function is available only to SAP.
Note
Once you have edited attributes of a node, the check box in the Attributes column of the node is marked. This gives you an overview of the nodes you have already worked on.

End of the note.
Optional: You can create attribute groups for a node. You can reuse these attribute groups during the modeling process when defining request and response attributes and do not have to create them more than once.
1. To create a group, choose Add New Group .
2. To add an attribute or another group to a group, choose Add Assignment to Group . Select the attribute or attribute group that you want to add and choose Choose.
3. To remove an attribute that is no longer required in a group or to delete a selected group, choose Remove.
For operational data provisioning, attribute groups can be used in the following cases:
- To represent reference fields for DataSource fields that contain currency amounts (CURR data type) or quantities (QUAN data types). If a DataSource contains reference fields, the groups are created automatically for the reference fields. If more than one field is assigned to the same reference field, the corresponding attributes are all arranged in one group. The suggested name for the group corresponds to the name of the reference field. You can overwrite the suggestion.
- If a DataSource contains more than one field for the fiscal year variant, create groups to assign the fields for the fiscal year (data element RSFISCYEAR) and fiscal year/period (data element RSFISCPER) to the appropriate fields for the fiscal year variant (data element RSFISCVAR).
.
Once you have defined all the relevant nodes and their properties for the model, choose Next to go to the next step in the roadmap.
More information: Defining Node Relationships