Configuring Business Context Viewer (BCV) Content

You use the configuration center as a central point of entry for Business Context Viewer (BCV) configuration and administration. You can define, edit, display and delete search connectors, queries, query views and all other BCV objects in the configuration center. You can also perform authorization and consistency checks, test search connectors and queries, and create, display, maintain, or delete access control lists (ACLs). On the starting page of the configuration center, the system groups BCV objects according to their type (for example, in the case of search connectors), and according to other criteria (for example, favorites and last used).

SAP recommends that you use the configuration center for all your BCV configuration and administration activities, for the following reasons:

• Not all of the functions of the configuration center are available in Customizing.

• The system locks all settings of the same type for other users if one user edits them in Customizing.

• Customizing is intended for administrators and advanced users to check and maintain settings, build own business configuration (BC) sets.

You can access the configuration center from your user menu by accessing the corresponding entry in the BCV user role.

You can only configure BCV when the following applies:

• You have activated the FND, Business Context Viewer Main Application /BCV/MAIN business function, and any business functions that are its prerequisites.

• You have the necessary authorizations, which are granted to you in one of the following ways:

  • In the Role Maintenance (PFCG) transaction, you are assigned to the BCV Administrator (SAP_BCV_ADMIN) role.

  • On the SAP NetWeaver Portal, you are assigned to the BCV Administrator (com.sap.pct.bs_fnd.BCV_ADMIN) role.

You use the context key to specify a combination of application and business object. This distinguishes the configuration of BCV in your application from any other configurations that might exist in the system.

As BCV is an application that several other applications can use at the same time in the same system, it is necessary to separate the configuration settings of the individual applications. The context key identifies the application using BCV and the business object it processes. When the application uses BCV in several instances, you must include the identifier of the business object in the context key.

If the application uses a namespace, the context key must start with this namespace. In this case, the namespace serves as the identifier for the application.

The context key influences the way the business objects in BCV, for example queries and query views present data.

The following table describes this influence on the different BCV objects:

Context Keys can only be defined in Customizing, navigated to through the following path: Cross-Application Components → Processes and Tools for Enterprise Applications → Business Context Viewer → Foundation, Monitoring → Define Context Key.

You define the business scenario where you want to use BCV by defining search connectors. You specify the kind of business analytics you want to perform using BCV. Your business requirements define the data providers and data provision technology that you must use.

A search connector establishes the connection between the data provision technology and the BCV by providing search access to a specific data provider at a specific destination (logical system) or list of destinations. The definition of the search connector includes the description of the selection attributes and the structure of the result data. The search connector delivers result data in a predefined form for the specified selection attributes.

The following types of search connectors are available depending on the type of data provision technology:

A search connector consists of input and output fields. BI, BAPI, and SES search connectors can also include a list of additional systems where the queries are executed.

BCV integrates search connectors with the following business objects:

• Query:

  Queries collect and analyze data provided by search connectors.

• Query view:

  Query views show the result of query processing on the Web user interface.

BCV has predefined search connectors to collect and deliver data of the different objects that is to be analyzed.

BI search connectors are based on BI queries. These can be called across different systems. You can define new BI search connectors if the following applies:

• You have defined BI queries.

• You must release the BI query to access BI queries as a data provider.

• You have configured the RFC destinations for the systems to be called.

• You have assigned the previously created RFC connection to the new logical system.

BCV can find cross-system application data using Enterprise Search (ES) search connectors. ES allows data from distributed systems to be connected and indexed. ES can determine which searches are available, either locally or across systems. For example, you can use a BCV query to search for orders from a vendor from distributed ERP systems.

BCV can search with search engine service (SES) search connectors within an SAP system for SAP ERP Business Objects using the TREX search engine technology.

BAPI search connectors are based on the implementation of an interface.

SAP delivers the following BAPI search connectors that search across the system for data:

• Material search (/BCV/CL_SIN_BAPI_MT)

• Quality message search (/BCV/CL_SIN_BAPI_QN)

• Sales order search (/BCV/CL_SIN_BAPI_SO)

The system transfers the data by BAPI call from the different ERP systems.

BCV can find application data using Web services with standardized interfaces. You can use web services, combined with application logic, as the data provision technology.

Web services are identified by the following properties:

• Available in standalone mode.

• Available as application functions.

• Can be used using the Simple Object Access Protocol (SOAP) Internet standard.

• Based on Extended Markup Language (XML) and Web Services Description Language (WSDL).

• Can be searched and published.

The web services that BCV supports, can be called synchronously, and extract application data using read-only access.

IS search connectors are based on InfoSet queries. You define the input and output fields in the InfoSet Query. The system transfers the input and output fields to the search connector and provides them as the maximum scope when defining a BCV query. As a result, when you define a BCV query, you can select individual fields from the maximum scope of the InfoSet Query fields according to your requirements.

You can define the InfoSet search connectors if the following criteria apply:

• You have defined InfoSet Queries.

• You have identified the input fields of the InfoSet Query as value fields (Value Only) or as value and text fields (Text and Value). This ensures that during query execution it is visible exactly which fields need entries.

SAP offers you InfoSet Queries for the following types:

• Link

• Table

• Logical Database (LDB)

• Report

You can use WF search connectors to search for workflow work items.

You need the following data to define a WF search connector:

• Object Type:

  The BOR object type defines the workflow that you search in (for example, BUS1178 for product workflows).

• Status Selection:

  The status selection defines the processing status of the work item that you are searching for.

• Period Selection:

  The period selection defines the time period of the creation data of the work item.

• Workflow Steps:

  If you select the Workflow Steps checkbox, you get a more detailed results list, that is, work items with steps.

The BCV query is a analytical tool that collects data from multiple data sources and displays the result to you in a query view.

The system processes queries every time you perform one of the following actions:

• Open the side panel.

• Change the focus object in the hosting application.

• Enlarge a quick view from the side panel.

• Start a query view or dashboard from the side panel.

• Change the input data of a query view.

• Perform a drill-down on a query view.

• Test a query, query view, or dashboard.

To improve system performance, the system buffers query processing. The non-initial call for the same query, input data, and user can take the result data directly from the query cache, instead of retrieving it from the data provider.

You can test queries without executing them from the side panel, or the view area. You can also display statistics of BCV queries.

A query has the following logical structure:

• Header:

  It contains information to identify a query (ID and description). It also contains administrative information.

• Input interface:

  It specifies the input fields required by the query.

• Result interface:

  It specifies the result fields provided by the query.

• Data selection description:

  It specifies the data records that the system retrieves, and the search connector (depending on the given field values) that the system uses to retrieve them.

• Data processing description:

  It specifies how the system fills the result fields from the retrieved data records (including grouping, aggregation, sorting).

BCV has predefined queries to collect and analyze data. It integrates queries with the following business objects:

• Search connector

• Query view:

  A query view displays the result of query processing on the user interface.

You can create new queries by defining a completely new query or by copying and changing an existing query. BCV has a set of predefined, standard queries. All standard query IDs begin with the number '1'. You can use these queries directly or copy them to the customer namespace by using an ID beginning with A to Z, changing them as needed.

For each newly created query, you must specify a unique query ID. The system fills the header of the new query with administrative information, for example, who created the query and the time of creation. Furthermore, the system performs a consistency check of the query definition before saving it.

To define a query, you must specify which objects the system selects in which data source, which fields of these objects the system returns, and how the system processes the returned data. The existence of queries is a prerequisite for the definition of query views that the system uses to display the results of query processing.

During the definition of a new query, you must assign a context key to the query. If you do not assign a context key to the query, the query is not visible in BCV during runtime. You must also select an existing search connector and define its query-internal ID, and its description. The definition of a new query also requires you to define query fields. Query fields define the structure and type of the data that the system sends to and receives from the underlying search connector.

On the Input Fields and Output Fields tab pages, choose Load Fields to load the input fields from the search connector automatically. You can select the required input fields from the result.

The definition of a query field in Customizing consists of the following:

• You specify the field ID.

• By selecting a type, you must define whether the system uses the field in the selection criteria for input data, as a result field for output data, or both.

• By selecting the origin of the query field, you specify whether the system links the query field to a search connector.

• You specify the internal ID of the search connector that is used in the query. You can specify one or two search connectors. If the query uses two search connectors, you must also enter a query join that describes how the system should combine the search connectors.

• You enter the ID of search connector field to specify an already existing search connector field that the system links to the query field.

• You specify the data element of the query field.

• You enter the data type of the query field. The system uses this information to determine what kind of data the field can handle.

• You enter a short description of the query field. The system uses this description as a tooltip for table columns representing this field.

• You enter the short, medium, and long field labels of the query field. The system uses these field labels as a header text of table columns or as a label text of chart axes representing this field.

When you define a new query you must define query result fields. Query result fields define the structure and type of the data provided by the query after query processing. You can use aggregation and grouping if you are interested in general information, while the available data provider provides information on a more detailed level. You can define aggregation functions only for numerical and period-based (for example, date, or week) result fields. You can define the order and direction in which the system sorts result data. The system can sort result data retrieved from the search according to the values of certain fields. You can also define a row limit in the query header to specify how many result records the query returns at most.

When you define a new query, you also define query input fields. Input fields are placeholders in the selection criteria of the query. During query processing, the system replaces input fields with specific values that you have entered manually or the system has determined automatically. By defining the sequence number of the query input field, you can specify the order of query input field input fields on the screen.

When you use selection criteria, you specify which data the system retrieves from the underlying search connector during query processing. A selection criterion consists of a field ID, a relational operator, and a field value. Optionally, you can use formulas in place of a field value in a search criterion, or to allow the enhancement of the result that the search connector provides with additional fields.

A query view represents the format that is used to present the result of a query to the user, for example, as a list, a chart, a form, or a display type that you have defined. The query view contains additional information that is relevant for displaying data to the user, such as settings, sort sequence and field configuration settings.

You use this object to specify the format in which you want to display your query processing results. Query views display in the following locations:

• On the Query Views in the side panel.

• On the Overview accordion item as quick views, which you can enlarge in the view area to see a more detailed view of query views.

• In dashboards.

Depending on the application using BCV, you can find a set of predefined query views in your system. You can use these as they are, or as templates to create your own query views.

You can use query view hierarchies that you can find on the Query Views accordion of the side panel. You can create a query view hierarchy based on the context key. Choose the Option menu of tray Hierarchical View to display the query view hierarchy on the Query Views accordion of the side panel.

If the presentation technologies are not enough for your analytical needs, you can implement your own, application-specific new presentation technology. BCV offers a Web Dynpro interface which supports the integration of application-specific presentation technologies into BCV.

The dashboard displays several query views to visualize a situation or a problem.

The BCV dashboard allows you to freely organize query views in a way that best suits your analytic needs. However, the CHIPs representing the query views cannot overlap. The layout provided by Page Builder assumes a rectangular grid, which you can freely divide in columns and rows.

You can use the BCV dashboard to synchronize the query views. To do this, choose Sync. The system broadcasts changes that you make to the sorter or filter in one query view to all other query views in the dashboard. If the query views contain data, such as fields with the same name, or identical meanings the system takes these settings over. You can place CHIPs that are not provided by BCV on the BCV dashboard.

Choose the Dashboards accordion in the side panel to access the list of dashboards available for the business object you are working with, To select a dashboard from the list, choose its name. To print the query views and snapshots contained in the dashboard, choose the print function.

Meanings describe the content of a field of a search connector, query, and query view. The system uses the customer-defined meanings to link these objects together. The output fields with a specific meaning can serve as input fields for another query view with the same meaning. You can define meanings at the level of search connector, or query.

You use the defined meanings at the setup of the input and output fields of the search connector. When you set up the fields of a query, the meanings of the fields of the search connector assigned to the query are taken over by the system. You can overwrite the meanings if necessary. The system also uses meanings to create branches of drill-downs. The query displayed on the user interface offers a set of meanings in its query output table. All possible drill-downs that use these meanings as input are available based on these meanings.

The overview is a list of query views displayed in the side panel. You can define different overviews depending on the context key. If the context key in the application changes (for example, you select a new business object), and if the side panel is not locked, the system automatically refreshes the content of the query views in the Overview accordion item.

Launchpads

The side panel contains accordion items that the system uses to display BCV objects, as quick views, query views, dashboards, and so on. The Launchpad accordion item contains a hierarchical tree of launchpad applications that you can use to start the application in a new session, based on the context key of BCV.

Drill-down means the execution of consecutive queries views, or the same query view, based on the context. You use this function to refine the data the system displays to get a more detailed view during analysis.

You can perform a drill-down in BCV if one of the following conditions applies:

• You have enlarged a quick view from the side panel, or executed a query view from the query view hierarchy.

• The queries whose query views you want to drill-down into have a meaning assigned to them.

• When you choose an existing link (may also be a point or bar in a chart), and the corresponding field has a meaning assigned to it, then the system displays a list of available navigation targets.
• The system retrieves the relevant navigation targets (query views, launchpad applications) according to the set of meanings, which consists of the meanings available up to the time of the drill-down, and the meanings transferred with the drill-down. For the first drill-down the navigation targets represent the context transferred by the application using BCV, along with the chosen meaning. A valid navigation target has at least each of the transferred meanings as selection parameter.
• If you select one of the navigation targets the system displays in a dialog box, then the system calls the target with the transferred set of meanings and its actual content. If more input fields are necessary than provided by the transfer, the system tries to retrieve these fields from previous drill-down steps. If this is not enough, the system displays a dialog box, asking you to fill in the mandatory input fields.

• The output fields of the underlying query can serve as post selection filters. To achieve this, you must define an appropriate query input field, and link it to the search connector output field by means of a selection criteria.

• The system adds a breadcrumb in the header for navigation and orientation. Additionally, the system provides a hierarchy of query view drill-downs executed so far, in the Drill-Downs accordion item of the side panel.

The system memorizes nearly every change you make in BCV as personalized settings. These changes include, reorganizing dashboards, changing table and chart settings in query views, and so on. In query views, the system administrator can specify if the system should save the settings as personalized or not.