Show TOC

Defining Model NodesLocate this document in the navigation structure

Use

In this step Roadmap step, you specify which data providers provide the basis for importing node metadata and which are the used for data extraction for the connectors of this model. The data providers specify the type of the data sources to be imported. You also specify the model nodes, assign node names and define the properties for the node attributes.

In this step, the nodes are displayed as a list but not in a hierarchy structure. You define the structure in the next step.

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

Type of Data

Recommended Model Layout

Master Data

The model usually contains a node for master data attributes and a node for texts. The nodes can be time-dependent or time-independent. If no DataSource exists for texts or no DataSource for master data attributes exists, 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 only consist of one node.

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

Example

Assume the following DataSources exist: ZCOMP_CODE_ATTR, ZCOMP_CODE_TEXT and ZCOMPANY_TEXT. The recommended model layout is:

  • Define a model ZCOMP_CODE that contains the nodes ZCOMP_CODE_ATTR and ZCOMP_CODE_TEXT.

  • Define a model ZCOMPANY that contains the node ZCOMPANY_TEXT.

Note

The way that you define master data models affects the way data is replicated in the SAP HANA database or BWA, because replication is performed on model level (connector). This means that the model nodes are replicated together in the SAP HANA database or BWA. If a model contains a node for master data attributes and a text node, this ensures this highest possible consistency for master data.

Transaction Data

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

Example

Assume there are two semantically DataSources connected to each other; one for the header data of an order (2LIS_11_VAHDR) and one for the purchase order items including header information (2LIS_11_VAITM). In this case, every DataSource should be contained in a separate model.

Note

For the purpose of performing searches, it can also be necessary to import the DataSource for header data into the model for positions. In this case, we recommend that you define the model with two nodes; one node based on the DataSource that contains header data and item data, and one node based on the DataSource for header data.

Procedure

1. Select Data Providers for the Model

Under Type of Metadata Provider, specify the data providers from which you want to import data sources as node metadata into the model. You can choose from BW-DataSource, DDIC, WCF BOL Data Provider, and Data Base Tables.

Note

Note that all model nodes must use the same extraction technology. This means that you can only specify the metadata provider type if the model does not contain any nodes.

2. Add Nodes to Model

  1. To create a new node, choose Create Node.

  2. Enter a name and a description of the node.

  3. 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, use the input help provided. For DDIC you can enter table names, view names and structure names as data sources (input help is not supported). For Data Base Tables you can enter table names.

    Note

    If you import a DataSource, the technical name and the description are applied by default as the node name and node description. The node name is cut off after a length of 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, then the system automatically imports both DataSources, if you select the DataSource for master data attributes. In this case, the system automatically specifies the DataSource for master data attributes as the root node.

  4. Specify whether you want the node to be the root node by selecting the relevant radio button in the Root column.

    The first node in the table is selected as the root node by default.

    Note

    If you select a different node as the root node, this node is shown as the uppermost node the next time that you call the screen.

    With master data DataSources, the DataSource for master data attributes must be specified as the root node.

3. Specify Properties of Node Attributes

  1. Select the required node to edit its properties.

  2. Change the node attributes in area Details: Attributes of Node ' <node name>'.

  3. To select the node attributes with the values that you want to extract and index, select the column Select (Select for Nodes) in the area Details: Attributes of Node ' <node name>'. Only selected attributes are available for further modeling and can be used in searches or for operational data provisioning.

    Scroll down to search for any further attributes available. As soon as you have selected an attribute, it is set to the first position in the list.

    Note

    You can also use the content of binary files attached to business objects (for example, documents) for the search. The attribute must contain a URL that points to the document. To resolve pure URLS (without destinations) that point to documents in a document management system, for example, you need to ensure communication is only performed using HTTP without user and password protection.

  4. Specify the properties of the selected node attributes. You can modify the properties for a node attribute using the following columns:

    • Description:

      Here you can add a description for the selected attribute or change the existing description.

      To access the description, simply click on the relevant column entry. Enter the description and press the tab key to move the cursor away from the field.

      Note

      For DataSources, the descriptions of the node attributes from the DataSource (or from the extract structure) are applied. We recommend that you should only make changes to the description of an attribute node, if you want the description in the DataSource to be different for analysis purposes. Otherwise we recommend that you should change the descriptions of the node attributes as little as possible.

    • Keys:

      Here you can specify which of the available attributes you want to be key fields in the model. By default, the system applies the selection of attributes that count as key fields. For DataSource-based nodes, for example, this means if the DataSource contains key fields, the system suggests the corresponding node attributes as node key fields.

      Key fields are relevant for foreign key relationships if you are modeling relationships (associations or compositions) between model nodes. They are also relevant during data replication in the SAP HANA database or BWA, as the records of a node are overwritten according to the modeled key. We therefore recommend that you check and maintain the key fields carefully.

      Note
      • If a DataSource does not have any key fields, the system specifies the first node attribute in the attribute list as the key field.

      • Note the following rules when defining key fields for DataSources that you want to use for operational data provisioning:

        • If the DataSource is language-specific, the LANGU-type field must be part of the key.

        • If the DataSource is not language-specific, the LANGU-type field must not be part of the key.

        • If the DataSource is time-dependent, 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 not time-dependent, 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.

    • Cont. Text (attribute contains readable text):

      You can specify whether the attribute contains readable text. You also set this property for attributes that use a URL to point to attached documents.

      Specify 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 and, if necessary, change the system proposal.

      Note

      If DataSources contain both master data attributes and texts, you can define the model so that it is not necessary to have a separate node and operational data provisioning (ODP) for texts. So that the master data ODP can 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 are read at runtime.

    • Conversion:

      Conversion of values with leading zeros so that the zeros are ignored by the search and removed for output.

    • Semantics:

      You can specify the (business) meaning of the node attributes.

      Possible values are:

      • Valid from (DF): The search does an internal validity check [ValidFrom – ValidTo].
      • Valid to (DT): The search does an internal validity check [ValidFrom – ValidTo].
      • Email (EM): Values with this semantic are displayed as a clickable e-mail address.
      • Internet Address (IN): Values with this semantic are displayed as a clickable Internet address.
      • Geo Location Coordinate Latitude (LA)
      • Geo Location Coordinate Longitude (LO)
      • Language Code (LC): Required for a multilingual search.
      • Object Type (OT): Restriction to particular object types, for example, you only want the search to find objects of a particular object type. Example: The connector Business Partner contains the following object types: person, organization, group. You can use this semantic to restrict the search to people.
      The following values are only available for DataSources that are to be used for operational data provisioning:
      • Calendar week (CW)
      • Fiscal Year / Period (FP)
      • Fiscal Year Variant (FV)
      • Fiscal Year (FY) Calendar year and month (YM)
      • Calendar year and quarter (YQ)
      • Calendar year (YR)
      • Calendar Quarter (QR)
      • Representative key (RK)
      • Calendar Quarter (QR)
      • Representative key (RK)
      • Calendar month (MO)
      You must consult SAP development before using the following values:
      • Client (C1)
      • Change Number (CN)
      • String with fixed length (FS)
      • Modification Date (MD): Restriction to particular change times, for example, you only want the search to find objects changed on a particular date.
      • SAP User ID (US): Required for path-based authorizations that do not use the standard user tables.
      • Content URL (CL): Specification of a URL whose content is to be extracted and indexed in the same field.
      • Searchable file (FL): Specification of a binary file whose content is to be indexed in the same field. This value is not valid in combination with SAP HANA.
      • Mime Type (MT): The MIME type is required for binary file extraction (see also searchable file (FL)).

      Note the following for DataSources that you want to use for operational data provisioning:

      • Nodes in master data models contain a node attribute called the representative key field of the node (or operational data provider). This attribute corresponds to the BW InfoObject represented by the node. Select the option representative key field for the attribute that performs this function.

        Note

        If you do not define the representative key field here, this does not result in an error during modeling, and the system attempts to determine the representative key field by evaluating the associations of the model. However, specifying the representative key field explicitly has the following advantages:

        • If a foreign key relationship is defined over several fields, the representative key field is the field for which the association is joined. Specifying the representative key field explicitly makes this fact transparent.

        • If the representative key field has to be derived by the system, this can lead to an unexpected result. You can avoid this by specifying the representative key field explicitly.

        Example

        The node 0COSTCENTER "Cost Center" has the key fields KOKRS, KOSTL, and DATETO. An association from 0COSTCENTER to 0CO_AREA (whose only key field is KOKRS) is defined using 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 a characteristic "Sending Cost Center" that references the node 0COSTCENTER, the representative key field for 0SEND_CCTR is also KOSTL.

      • Select the option Valid From or Valid To for the 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.

      • For selectable language key fields with the data type LANG (like LANGU), the system proposes the option Language Code. If the language key field is not flagged as selectable in the DataSource, the system does not propose this option. In this case, select the Language code option manually.

        Note that the language key fields must be of type LANG.

      • For DataSource fields that are to be assigned time characteristics (for example, 0CALMONTH or 0FISCYEAR), select a suitable option for the semantics (for example, Calendar Year and Month or Fiscal Year). If there is a system proposal, check it and adjust it if necessary. During the TransientProvider runtime, the system maps these fields to the corresponding time characteristics and can provide the master data attributes and hierarchies.

      Note that if you select the option Language Code, the search will not be language-specific, and only results in the logon language will be output.

    • No Extraction: You can specify here whether the attribute is to apply to the display and access for the search, but not to the extraction.

      Example

      In the classification search, there is an unindexed dummy field whose content TREX converts to 7 or 9 real attributes during the search.

    The following properties of the node attributes are also displayed:

    • Type: Specifies the attribute type.

    • Name in Backend: 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 only available to SAP.

    Note

    Once you have processed the attributes of a node, the checkbox in the Attribute column of the respective node is selected. This gives you an overview of the nodes you have already worked on.

  5. Optional: You can create attribute groups for a node. These attribute groups can be reused later on in the modeling process when defining query and response attributes, so that you do not have to create them again:

    1. To create a new group, choose Start of the navigation path Add Next navigation step New Group End of the navigation path.

    2. To add an attribute or another group to a group, choose Start of the navigation path Add Next navigation step Assignment to Group End of the navigation path. 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 (data type CURR) or quantities (data type QUAN). If a DataSource contains reference fields, the groups are automatically created for the reference fields. If the same reference field is assigned to several fields, the corresponding attributes are all contained in one group. The proposed name for the group corresponds to the name of the reference field. You can overwrite the proposal.

    • If a DataSource contains more than one field for the fiscal year variant, create groups to assign the fields for fiscal year (data element RSFISCYEAR) and fiscal year/period (data element RSFISCPER) to the relevant fields for the fiscal year variant (data element RSFISCVAR).

    .

  6. Once you have defined all relevant nodes and properties for the model, choose Next to go to the next step in the roadmap.

    More information: Defining Node Relationships