SAP Analytics Cloud (SAC) is a cloud-based analysis instrument providing numerous characteristics and functions for data visualizations and analysis. The story designer enables users to create reports based on data models and make theses objects accessible to a wide range of users. However, and particularly in international organizations, there is the multilingual challenge to be faced in making theses created reports useful and accessible. For example, a colleague from Poland might want to activate the German created report in Polish to analyze the figures and findings without language barriers.
Given use of a live link to the data source, then this source itself provides the multilinguality. But using an import link requires a number of steps to display the data in the user’s log-on language. One of the prime functions in this connection are Public Dimensions. Public Dimensions are SAC objects which can be reused in several SAC data models and enabled for other users.
This blog will explain how to implement Public Dimensions in various languages. We will show this in detail together with all the required system settings on the basis of a specific application case. The idea in this scenario is for general ledger accounts to be extracted from a S4HANA system and modeled in SAC as a multilingual Public Dimension.
Implementing an SAC Public Dimension in various languages
Activation of the API in SAP S/4HANA
The API API_GLACCOUNTINCHARTOFACCOUNTS_SRV is a standard SAP OData Service providing access to the general ledger accounts in the Chart of accounts. This API can be used as a data source in SAC to implement Public Dimension in various languages. If needed, this service firstly needs to be activated in the respective S4H system. Here in the SAP GUI per transaction code: /IWFND/MAINT_SERVICE add the required service.
Activate services by way of the SAP GUI
SAP S/4HANA API has two kinds of fields for G/L accounts: a G/L account in the Chart of accounts and G/L account in the Chart of accounts Text. SAP provides more clear-cut details: (https://api.sap.com/api/API_GLACCOUNTINCHARTOFACCOUNTS_SRV/overview)
The G/L account field in the Chart of accounts: A data field saving the numeric value of the G/L account. It is for presenting the account number and is used to record the financial transactions of a company. This field is typically used in accounting operations, financial reports and analyses.
The G/L account field in the Chart of accounts Text: Is, in contrast, a text box in which the description or name of the G/L account is saved. It is used to provide extra account information, such as its purpose and use. This field is normally used in finance reporting/analysis and in master data management.
The main difference is that the G/L account field in the Chart of accounts has the numeric value of the GL account whilst the G/L account field in the Chart of accounts Text stresses the G/L account description. Thus in this example the text field also provides the values for the respective language.
Creating a Public Dimension
Given activation of the required API in the Backend, a request can then be transmitted from the SAC. However, firstly a generic public dimension is needed which can be created with the path: Modeler -> Public Dimension. Each Public Dimension has by default a key and a description. If wanted, other attributes, hierarchies and currency information can be activated.
Creating Public Dimension
In the dimension details the language property of the key characteristic is definable so that a key can have several languages. These languages are prescribed by SAP and currently limited to 49. Basically the language is implicitly added as an extra key so that 1-49 descriptions are extended to a real key.
The top right translation button (in yellow) is also for making manual changes to languages.
Manual change to translation
Change entry by way of text field
Change entry by way of text field(s)
This is the key which clearly identifies a data set. Only one characteristic can be defined as a key in a public dimension. If clearness is only to be defined from two instances, then the Member ID must be concatenated. In this case the Member ID is defined as /<G/L Account>. It can be clearly seen here that the value from the G/L account 1000 occurs 5-times. This only becomes clear when the Chart of accounts is added as information and the language description can thus be allocated to the correct key.
The system implicitly creates the description and Member ID as field. Creating more attributes means providing the data with extra context regarding information. The data sources determine if extra attributes are extendable, if required. In the case of API API_GLACCOUNTINCHARTOFACCOUNTS_SRVa great many other attributes per key are returned:
API provides very many attributes
In addition, attributes can be used to filter and group data in visualizations for more detailed data analysis by users. In our example, we will firstly only populate the key characteristics and Account Group.
Creating attribute covers
Using the API
Creation of the Public Dimension also created a cover. What is firstly needed to populate it with information is the API, which was activated in the first step. For this, change to the Data Management view in the Workspace and click the Button Data from a Data source import.
Populating Public Dimension Step 1
Also select the system affected since we want to extract data from a S/4HANA.
Populating Public Dimension S4H Step 2
With the system already integrated via the Cloud Connector in your SAC, the required connection then appears in the dropdown window.
Dropdown window Connection Step 3
Under the external service name API_GLACCOUNTINCHARTOFACCOUNTS_SRV the service can be found and the SAC provides both fields/tables to the API. Should the service not appear here, then re-check the service activation in the source system.
Service name in SAC Step 4
A_GLAccountInChartOfAccounts supplies the numeric characteristics which we will firstly populate the pendants with from the Public Dimension. For this, drag & drop the required source fields to Selected Data.
Selecting source fields Step 5
The system now automatically tries to map the source data from the data source into the pendants from the Public Dimension. Errors like these here are marked in red as no key has been mapped into the ID dimension.
Mapping and error notification Step 6
Using the data manipulation function, define the data as field key from Chart of Accounts and G/L Account with separator.
Defining key for Member ID Step 7
Then add the Dimension ID field since the key is a mandatory field.
Assign Dimension ID/ Member ID to the newly composed key Step 8
Completed! The numeric data has now been successfully imported.
All attribute characteristics have been added
The next step involves accessing the texts. The procedure is similar although the required attributes differ from one another. The entire key from G/L Account and Chart of Account is needed to allocate the texts. The Language Key is an important concept in working with texts. This key is a code which identifies the language of the text to be created or edited. It is used to ensure that the text for users speaking this language is correctly shown. As a rule, the language key is a two-digit code standing for the language. For example, “EN” stands for English, DE for German and “FR” for French. A list of all language keys in S/4HANA can be found in the SE63 transaction. The assigning is done in Dimension Mapping onto the pendants in the Public Dimension target.
Source data: Key information, Language Key and long texts Step 1
Allocation and manipulation of the source data. In the process, the Language ID is populated with the language code and with the description based on the code in question.
Mapping for the text descriptions in different languages.
After loading the texts, this allocation is done, for instance, in Account 1000. (Sequence varies)
Account 1000 display in English
Account 1000 display in German
Using the Public Dimension
To use the generic Public Dimension a data source is needed for listing variable data to the account and Chart of accounts. This permits the generic object to be referenced. In our Use-Case this is a straightforward SAP Business Warehouse Query.
Activating the variable data based on a BW Query:
Query after activation in AfO
Create new SAC data model with the created Public Dimension object. The Query-based loading is undertaken in the second step.
Data model when using the created Public Dimension
Importing data from the BW Query into the SAC data model
Query objects used to load the data model in the SAC
Since our data model is a SAP BW Query and the G/L account Characteristic an info object already clipped to the Chart of accounts, the source object G/L account is shown in the correct format as is the Public Dimension. If you extract data from a different data source e.g., file upload, then you should make sure you know the format it is in in your Public Dimension key and possibly adjust them with data manipulation tools in the SAC.
BW Query data source
Mapping the G/L account from source with Public Dimension
Mapping into the Public Dimension
A Story can be created in the final step based on the created data model.
Here the outcome of a straightforward widget using the Public Dimension in the log-on language (de):
Display language German
The data access language can be changed via the Profile Settings:
Changing display language
Refreshing the Story and the values are shown in English:
Display language English
Limiting texts in the Application/Story
However, in the described Use case only the descriptions based on the language codes on hand are translated from the source system and saved in the dimension.
Since a Story can additionally comprise information not forming part of the data model, such as static texts and page names, SAP gives the Story creator the chance to maintain them using the language set in the viewer’s user account.
To this end, the translation must be activated in the Story Properties in the Story.
The story elements are actually translated with the translation function in the SAP Analytics Cloud which the navigation bar leads you to. There is also the scope to import all elements per XLIFF file or directly in the translation menu.
XLIFF files are based on XML (eXtensible Markup Language) and therefore structured information. They include the source text to be translated and appropriate Meta data in the xml format. With content not dependent on the SAC, this format permits structured and consistent working. By using XLIFF files, companies can cut back on outlay, improve consistency and thus reduce the extent of collaboration between stakeholders in the translation process.
For this, export the ongoing status just once and open the file, for example, with Notepad++. Under the declaration, enter the target language, per target-language= :
Then define the translation with this syntax underneath the translation structure
ÜBERSETZUNG. In so doing, each translatable element is wrapped in a trans-unit.
Make sure that the text fields are shown twice in the generated XLIFF file. These define the Mouseover property and text field display in the Story and are defined with the appropriate data typing.
- The text field is defined with the “x-urn:x-sap:sls-mlt:xhtml-ph” data type
- The Mouseover on the text field is defined as “x-urn:x-sap:sls-mlt:java:messageformat” data type
Re-import once all translations are dealt with. It is important that the file is saved under <_>.xlf to ensure its interpretation.
Alternatively, the translation can be directly undertaken in the SAC menu. The target language needs to be selected here and the text input fields filled in next to the original text. Since translators often possess no authorizations in the SAC system and administrators do not always define valid corporate-wide translations, the XLIFF file variant can become the optimum-selectable option.
Our handling recommendation is a clear one for using Public Dimension and thus the multilinguality of characteristics. In this way, you ensure designation consistency and precision in the various languages. This can enhance data precision and cut back on errors. SAC automatically selects the matching language version based on the system’s language settings. Moreover, the use of Public Dimension in import data models is recommended as being essential. Utilizing this kind of generic object in data models will enable you to view your data in a consistent and standardized way. By creating a number of dimensions for collective use in various models and analyses, you ensure that everyone in your company uses the same definitions and terminology. All in all, the SAC public dimensions allow you to gain a deeper insight into your data, enhance data precision/consistency and improve collaboration and communication in your company. In addition, the translation variant of the SAC Story elements via the translation cockpit provided is easy to use and fulfils its purpose. If larger formatted translations are to be scaled and they are linked to corporate guidelines, then it is recommended defining a workflow via XLIFF files to accommodate all stakeholders in the translation operation.