Integration of BW WorkSpaces Into LSA++

The use of BW Workspaces is just one component of a well-designed BI data warehouse. This overall deliberate design architecture of your BW system is the concept of the LSA — or on BW on HANA, LSA++. The ++ means that when BW is on HANA, your LSA can be much more flexible, using native HANA features and BW Workspaces. Although this LSA++ concept is beyond the scope of my article, I have included an LSA++ graphic (Figure 3) that SAP has posted on its Web site. This time, however, I have highlighted the BW Workspace component to assist you in grasping the overall positioning of BW Workspaces.

As you can see in Figure 3, the BW Workspace is positioned next to the architected data marts (cubes) and Propagation Layer. This new part of LSA++ provides you with flexibility with direct access to BW queries and an easy ad hoc modeling framework that is outside the formally controlled objects of the original LSA architecture.

Creation and Maintenance of Workspaces

The process of creating, maintaining, and using BW Workspaces is a shared effort. There are two parts to the process, each positioned by SAP to be performed by a different group. The first half of the process, which I call initialization of the BW Workspace, is performed by BW back-end pros using the SAP Windows user interface (UI).

The second half of the process is BW Workspace design through use of the Workspace Designer tool. This task targets advanced business analysts or possibly back-end professionals. In any case, users of the Workspace Designer need to have some database background. This part of the process is Web based.

Finally, remember that the reporting on BW Workspace objects is no different from reporting on other BW objects.

Now I break down the back-end initialization process step by step. I also briefly discuss a related mass maintenance tool as it provides a central view of all the Workspaces and how many resources they consume. I then describe in detail the BW Workspace design process.

Exactly which group performs these tasks is a company-specific decision. In any event, BW architects and analysts must know the capabilities of Workspaces to properly deploy them.

Initialize a BW Workspace from the Back End

As noted, the idea of BW Workspaces is a shared effort between IT and the business. The BW back-end team starts the process and sets limits. This primarily involves one central transaction and several tabs within the resulting screen that concern the following topics:

• Initialize a BW Workspace
• BW Workspace basic settings
• Exposing InfoProviders to a BW Workspace
• Other BW Workspace information
• Authorized users of a BW Workspace
• Mass Maintenance of BW Workspaces

Initialize a BW Workspace

Use transaction code RSWSP to create and initialize a BW Workspace. After executing RSWSP, the next task is to provide a basic technical object name and description. You then move to the core maintenance screens.

Consider the BW Workspace technical name carefully. Like all object names in BW, it is unique. The description, on the other hand, is not checked for uniqueness. Many implementations use the technical name of the BW InfoArea as part of an authorization scheme, to decide, for example, whether only FI team members can execute a query in a financials InfoArea.

Just like normal InfoAreas, the BW Workspace’s technical name can be used as part of an authorization scheme. Therefore, paying attention to the naming convention is critical because the technical name cannot be changed later. Consider a possible technical name using a combination of the business functions and the group within the company targeted to use the Workspace. For example, you can designate FIMED1 for use by the finance group of the medical division.

BW Workspace Basic Settings

After you enter the basic name and description and press Enter, you access the details of the Settings Tab (Figure 4). Some obvious and less obvious settings are under this tab.

The Expiry Date field can be used to stop access of the Workspace to the Workspace Designer. The object is not deleted when the expiration date passes, but from the perspective of the Workspace Designer, it behaves that way. A simple adjustment to this date restores all functionality.

In addition to the technical name entered on the first screen, the system allows a prefix, which is an extension of the technical names of the objects used in a BW Workspace and can be used to organize and tag the objects created later in the Workspace Designer.

Next, you can enter primary and back-up contacts. Maybe contact 1 is the name of an IT person, and contact 2 is the name of a business user. These must be valid users in the system. On one hand, this step forces you into accurate data maintenance, but on the other hand, it prevents the use of more generic users such as China IT manager or China sales analyst. One nice feature is that the email icons  next to these users allow you to send a quick message, such as when a change to a BW Workspace is made.

In the screen shown in Figure 4, the Settings for Local Providers section provides you with the option of initially entering a MultiProvider, rather than later adding this under the Central Providers tab. They are related, yet putting the reference to the MultiProvider in the settings tab has a more robust effect. Although you see the part providers of the MultiProvider on the Central Providers tab as they are inherited from this entry on the settings tab, they are not selected by default, just proposed. The larger effects of the MultiProvider entry on this tab are:

• If a BW Workspace Designer later uses part providers from the MultiProvider, as a part of a CompositeProvider in the BW Workspace, the linking (unions) needed are defaulted from the MultiProvider entered on this Settings tab.
• Any queries that exist on the MultiProvider can be used as a reference query for a later query on the Composite Provider subsequently created in this BW Workspace.
• Most important, if BW analysis authorizations are linked to the MultiProvider, the authorizations are inherited by the CompositeProviders subsequently built in this Workspace. This benefit is significant, as the whole process to request authorizations at many companies is so slow that it could discourage the adoption of BW Workspaces.

Also in the Settings screen, the Maximum Memory and Maximum Number of Local Providers fields are features designed to limit the complexity of the BW Workspaces. In my opinion, the administrator should focus more on controlling the memory allowed rather than the number of Local Providers. You might add a lower limit, maybe four Local Providers and 100 MB, just so that you can be warned when these are violated, thus keeping an eye on growth. Warning (yellow) icons are provided when each metric reaches 80 percent of the limit.

The Settings for CompositeProviders section provides controls that might be needed for the less experienced designer using the Workspace Designer tool. This is especially true for the setting that allows the designer to create a join on a column that has non-unique entries. Figure 5 shows how this can easily happen and cause inaccurate results.

To eliminate the possibility that these joins are allowed, thus producing bad results, do not select the check box Non-Unique Join Columns Allowed.

The other two settings are less complex, but from a back-end perspective are important. Note that the usable results from the efforts of building a BW Workspace are a new provider type called a CompositeProvider. The master data setting on this data is needed if your users create CompositeProviders from locally sourced master data (not snapshot queries). Although this setting is a nuance you should understand it because it affects your master data IDs (SIDs) in the global BW. There is a possibility that the system needs to create an SID if the master data does not have an existing SID in BW already. In some cases, the BW Workspace administrator may want to prevent the BW Workspace Designer from activating the CompositeProvider if a resulting query has the possibility of creating new master data SIDs at query runtime.

When it is selected, the setting Creation of Master Data Allowed field only generates a warning for this situation. If it is left unchecked, then when a union is detected, an error occurs on the activation of the CompositeProvider. Remember, I am just discussing the possibility of an SID, not new attributes.

The final setting (Key Figure Copying Allowed) allows the restricted and calculated key figures (for example, February sales and sales revenue) that were established against the underlying MultiProviders to be used when accessing queries later built for the CompositeProvider. To allow the reuse of these central provider-based key figures, select this setting.

Exposing InfoProviders to a BW WorkSpace

On the BW Workspace general settings screen, I consider the Central Providers tab (Figure 6) as the guts of the BW Workspace. In this tab the administrator exposes objects (mostly InfoProviders) existing in the global BW system to be used and improved by BW Workspace designers, such as by adding Local Providers and building composites.

Once expanded, the left side of the UI shown in the screen in Figure 6 enables you to access all the InfoProviders existing in the BW system. In addition, you can click the data sources icon, which is positioned next to the refresh icon, to toggle the list to show Data Sources. When you use data sources, they behave as enablers for later access to the data when you create a Local Provider.

In the example shown, the employee data source was made available. I assume that this data source, DataSource Employee, is a database-connected DataSource, and later in the process, the BW Workplace designer or power user uses the data source for a Local Provider. The details of where that data is sourced from are not needed (they are under the covers of the DataSource).

When the designer uses this data source in defining a Local Provider, the external system is read and a snapshot of it becomes the basis of this Local Provider. Because guaranteed access to the data is needed, if the DataSource ultimately is getting data from a file, this file must be stored on the server. If your warehouse already has a DSO built from a DataSource, using the DSO as an InfoProvider-based central provider in the workspace might make more sense. Remember from the note above that InfoProviders are exposed rather than causing a load of the snapshot of data to be generated as described above with the DataSource Option. Also, remember DataSources are not cleansed, but rather are based on source-defined fields.

In the creation of the BW Workspace, the process of assigning central providers is tantamount to creating a mini-BW system for a specific reason. For example, in the sidebar “Use Cases for BW Workspaces,” if a MultiProvider has six part-provider cubes covering three years of data for the United States and China, your user’s mini warehouse and BW Workspace might just need the cubes for this year and last year for just the United States. You might add other objects, such as master data (using InfoObjects as InfoProviders) and other DSOs that might be in some way related to this core data, to form your mini warehouse.

In addition to choosing the providers themselves, you can hide irrelevant parts of the object by not exposing (i.e., unmarking) the dimensions or characteristics after you move the object to the right side of the UI (Figure 6). This step further limits the data exposed to the BW Workspace. Once you include (i.e., move to the right side) and select all the BW warehouse objects that can be needed by the users (designers) of your BW Workspace, the next step is to activate the BW Workspace. This is done in the normal way with the matchstick icon (not shown in the screenprint).

Other BW WorkSpace Information

The remaining tabs in transaction RSWSP are more informational. Data is collected on these tabs to help back-end professionals manage the BW Workspace. A back-end professional does not enter data in these tabs; rather, various activities of other people populate the fields. I discuss each tab further.

Local and Composite Providers Overview

The tabs for Local Providers and CompositeProvider (Figures 7 and 8) are only populated through work done by the BW Workspace designer. These figures show the tabs populated with objects, which is just for your convenience. Normally, at this point in the process, when no design work has been done, they would be empty. In my example screens, they are populated because this later design work has already been done.

The power user populates the Local Providers tab later in the process (Figure 7). The power user accesses the Web-based BW Workspace Designer and creates and uploads Local Providers to the underlying database (HANA or BWA). As you will see in detail in the article “Introducing the Front-End Workspace Designer,” these Local Providers are based on snapshots of execution of queries, the load of a DataSource, or the load of a file.

Similarly, power users also create CompositeProviders later in the second part of the process of building the workspace by using the Workspace Designer tool set. CompositeProviders allow the join or union of both local and central providers. I think of CompositeProviders as the heart of a workspace. For your information, these designer-created objects are listed on this tab.

Again, only after Local Providers and CompositeProviders have been created in the Workspace Designer are they visible with their status in the Local Providers and CompositeProvider tabs.

Authorized Users of a BW Workspace

The final tab, Users (Figure 9), shows the users with authorizations to use the BW Workspace. In my example, no user-specific access is granted. My user has SAP ALL access (not shown).

Mass Maintenance of BW Workspaces

Another back-end option is the mass maintenance of BW Workspaces transaction RSWSPW.  This transaction is shown in Figure 10. With it, you can group Workspaces in folders for organizational reasons — for example, US_FI_AP for Workspaces belonging to the accounts payable group. From the folder tree, you can double-click to the editing of a specific space, which is returning back to transaction RSWSP.

Here are some of the features in this transaction:

• You can drag and drop a BW Workspace to a different folder.
• You can toggle between a list view and a detailed view of a single BW Workspace, which allows you to change and activate multiple BW Workspaces
• A mass check function is also available via the path Environment > Collective Check
• Deleting the whole BW Workspace (every related object) or just the contents of the Local Providers is available via the path Workspace > Delete or Delete Contents (global BW content InfoProviders are not affected)
• Finally, an advanced search function using path Environment > Detailed Search lets you search for BW Workspaces with specific properties (Figure 11)

An example of a benefit of the advanced search screen is using it to find existing BW Workspaces that contain the InfoProviders required by a business analyst before you decide that you need to create a new workspace.

Learning Exercise: Front-End Tasks

Now that you have read this article, which focuses on back-end tasks, you can go to the article “Introducing the Front End Workspace Designer,” which picks up where the super analyst tasks begin. This learning exercise is intended to show you how intuitive the front-end tasks are. Here is how to get started:

1. Access the WEB BW WorkSpace Designer 
2. Load Local Providers
3. Build CompositeProviders by join and union of Local Providers and the exposed InfoProviders from the back-end team
4. Create queries or use the default query for the BW Workspace

You first have to access the Workspace Designer. This part is not intuitive unless you are using SAP NetWeaver Portal. In my article, I use the newer SAP NetWeaver Business Client (NWBC).

The BW Workspace designer is a collection of Web Dynpro applications that as the name suggests display data using Web-based technologies. The SAP methods for displaying these applications to an end user include SAP NetWeaver Portal or the new NWBC. The advantage of using NWBC is that it does not require a separate portal box running Java. Rather the Web Dynpro application in the SAP ERP Central Component (ECC)/BW box can be directly used by NWBC, which is installed as a rich (PC) client application. NWBC can then be used to display SAP GUI transactions as well as Web-based ones. This is shown in my example of the BW Workspace Designer (one such Web Dynpro application) shown below. Transaction NWBC launches the UI from SAP GUI. In either case, to get started you need access to the following services:

• MY Workspace =  RSL_UI_MY_WORKSPACE
• Create Composite Providers  = RSL_UI_CREATE_COPR
• Create Local Provider = RSL_UI_CREATE_PROVIDER
• Workspace Tools = RSL_UI_CHANGE_WORKSPACE

Use the tabs and links presented in these services to upload Local Providers and then continue to composites and queries. You can check the article “Introducing the Front-End Workspace Designer” for any details you may not have intuitively figured out,  but try to figure it out on your own to see just how intuitive it is before you look at the front end article.

One final note: If you want to learn about BW Workspaces in person or via virtual  classroom training look up BW362 training from SAP Education.