sap lumira что это

What’s new in SAP Lumira 2.4

The release of SAP Lumira 2.4 brings lots of new features to SAP Lumira Designer and an updated SAP Lumira Server add-on for the BI Platform. Below are some highlights of the new and modified features of Lumira 2.4.

SAP Lumira Discovery

There are no enhancements to SAP Lumira Discovery 2.4 as SAP Analytics Cloud is the primary strategic Analytics Solution moving forward for the use cases covered by SAP Lumira Discovery. All the new innovations and enhancements will be delivered with SAP Analytics Cloud and SAP recommends customers leverage SAP Analytics Cloud for Self Service Data Wrangling and Data Visualisation. For more information on SAP Analytics Cloud refer to https://www.sapanalytics.cloud/

Upgrade path

SAP Lumira Server for BI Platform 2.3 and lower versions are NOT supported on SAP BI Platform 4.3 due to technical limitations. It is recommended that customers on SAP BI Platform 4.3 upgrade to SAP Lumira Server for BI Platform 2.4 to enable Lumira functional features.

SAP Lumira Server 2.4 is also fully compatible with BI4.1 and BI 4.2

New and Modified Features in SAP Lumira Designer

Tile Container for responsive scenarios

You can use the Tile Container component to create a responsive application that automatically adapts to the quantity of sized tiles per row, automatically wrap them, according to the browser size of the viewing device

Export Enhancements

Export to Excel

The Export Excel technical component has been enhanced for the Crosstab. The following enhancements have been made to the Export Excel feature:

Export to PDF

Export to PDF now supports export of all selected components within a Pagebook and allows the user to select pages for export. For report exports, components selected for export that are contained within a Pagebook can now be exported even if their parent page is not displayed at the time of export. This is done by selecting which Pagebook pages should be available at export time, so that the selected component(s) within can be exported to PDF (assuming appropriate component visibility has been selected).

You can export a crosstab with collapsed or expanded hierarchies on the column headers and row headers. If your crosstab contains hierarchies on the column headers and row headers, these hierarchies are also shown when exporting to PDF in a report style. When the hierarchy is collapsed in your crosstab at the time of export to PDF, the output displays the indentation and expansion symbols. When the hierarchy is expanded at the time of export, this too is reflected in the export to PDF.

Export to PDF now supports a wider range of languages. The locale of the user’s session determines the language to use for export to PDF and if there are any characters of a different language in the application, metadata etc. they may not be exported correctly to PDF. Only one language can be exported to PDF, per application

Export to PDF now includes Arabic and Hebrew and displays them in right to left format.

You can now apply header formatting to Microsoft Excel exports. You can select from the three predefined options of the Header Formatting property of the Export Excel technical component during design time or use API scripting to choose the predefined options during runtime.

Chart and Table Enhancements

Chart

You can enable/disable ad-hoc data comparison via script API. Thus it is convenient for end user to trigger this functionality by clicking on a button or other UI element to start the ad-hoc data comparison rather than only via context menu on charts

Chart Animation can be enable or disabled at application design time.

Table

You can now define a restricted key figure for BW systems at application runtime by using the context menu in a table.

Configure Message Display

Now an application developer can configure their own info/warning/error message for Lumira designer applications

New and Modified Features in SAP Lumira Server

Lumira Application Available in BI Launchpad

You can access the Lumira application from the SAP BusinessObjects Business Intelligence (BI) launchpad. The functionality remains the same as in the old BI launchpad.

Scheduling to Multiple Destinations

The reporting feature in SAP Lumira, can now be used to schedule to multiple destinations similar to that in SAP BusinessObjects Business Intelligence. The destinations supported are: Default Enterprise location, BI Inbox, and email.

These functions can also be accessed from SAP BusinessObjects BI Launchpad > Reporting.

Источник

SAP Lumira

Содержание

Используя средства бизнес-анализа, SAP Lumira подходит для выполнения задач:

2014: Интеграция Lumira 1.19 и SAP BusinessObjects 4.1

15 сентября 2014 года стало известно об интеграции средств визуализации и исследования данных SAP Lumira 1.19 с флагманской BI-платформой SAP BusinessObjects 4.1.

Новый интерфейс Lumira

Это обновление ориентировано на менеджеров, не имеющих ИТ-подготовки, но, тем не менее, желающих самостоятельно в режиме самообслуживания строить и исследовать предиктивные модели, используя наряду с корпоративными и дополнительные наборы данных. В частности, в Lumira теперь задействованы преднастроенные модели данных BusinessObjects Universes, а построенные с помощью Lumira диаграммы, графики и приборные панели легко экспортируются в BusinessObjects, где доступ к ним регулируется общекорпоративными правилами и ролевыми политиками.

2015: Интеграция SAP Lumira и Google Sheets

Скриншот окна приложения, 2014

SAP Lumira допускает наряду с данными из корпоративных приложений использование данных электронных таблиц Google Sheets. Планируется реализовать сохранение визуализаций и инфографики, созданных в Lumira, в сервисе хранения Google Drive. Файлы можно будет сохранять в форматах Google Docs. Система управления кадрами SuccessFactors с интерфейсом Fiori также будет интегрирована с Google Drive, а использование приложений Google Apps будет доступно непосредственно из Fiori.

Источник

Lumira

Визуализация данных для принятия решений на любом уровне.

Это просто. Попробуйте сами.

Оживите данные Вашего бизнеса

SAP Lumira – это решение бизнес аналитики для визуализации данных, являющееся частью платформы SAP Business Objects.

Визуализация данных из множества источников:

Архитектура SAP Lumira 2.0 базируется на механизме SAP Design Studio и предоставляет два пользовательских интерфейса:

SAP Lumira Discovery

для целевого поиска и визуализации данных и для создания и обмена сторибордами.

SAP Lumira Designer

для работы с профессиональными корпоративными дашбордами, которые позволяют с легкостью использовать сториборды Discovery повторно за счёт функциональной совместимости.

Полная совместимость.

Функциональная совместимость интерфейсов Discovery и Designer делает продукт SAP Lumira 2.0 наиболее эффективным инструментом анализа с точки зрения обнаружения данных и самообслуживания. Быстро создавайте простые сториборды и дорабатывайте их до профессиональных макетов.

Интуитивно понятный интерфейс SAP Lumira Discovery позволяет бизнес пользователям самостоятельно просматривать и редактировать диаграммы, сокращая нагрузку на IT отдел. Все документы и источники данных доступны в едином интерфейсе.

В то же время, технические специалисты могут проектировать более сложные представления данных, которые будут доступны бизнес пользователями, с помощью SAP Lumira Designer.

Просматривайте документы Lumira в удобном веб-интерфейсе. Дашборды, созданные как в Discovery, так и в Designer, доступны пользователям в общем репозитории отчетов — BI Launchpad.

Discovery. Self-service. Визуализация на лету.

SAP Lumira Discovery обеспечивает высокую гибкость, когда речь идет об исследовании данных. Все представлено на одном экране с сеткой повышенной резкости. Всплывающие по клику правой кнопки мыши меню упрощают процесс визуализации.

Интерактивное управление

Добавляйте в представления элементы управления и интерактивные фильтры, которые покажут различные срезы данных прямо во время просмотра.

Live («живое») соединение. Без репликации данных.

С SAP Lumira 2.0 теперь возможно как live-соединение с SAP BW и SAP HANA, так и автономный режим. В случае live-соединения данные хранятся в BW или HANA, но не дублируются, в отличие от автономного режима, что позволяет избежать передачи данных за пределы корпоративной сети.
Live-соединение делает SAP Lumira отличным инструментом работы с BW и HANA.

Просматривайте представления данных на любых устройствах, включая мобильные, как в приложении, так и в браузере.

Обновление данных в дашборде на основании источников позволяет в любой момент получить представление о текущей ситуации в бизнесе.

Публикуйте созданные представления на платформу SAP Business Objects Business Intelligence или отправляйте их коллегам. Делитесь отчетами с другими пользователями.

Designer. Аналитические приложения.

SAP Lumira Designer обладает наименьшей сложностью в сравнении с большинством других инструментов для бизнес-аналитики. В то время как разработчик может нуждаться в кратком изучении инструмента, стало возможным разрабатывать дашборды и приложения, которые обладают мощными аналитическими возможностями, но в то же время остаются простыми для конечного пользователя.

Простота для конечного пользователя.

Разнообразие компонентов и богатый набор визуализаций делают SAP Lumira Designer инструментом, способным предоставлять интуитивно понятные для конечных пользователей решения, которые требуют минимального обучения или вовсе его не требуют. В дополнение к этому очень легко разрабатывать приложения с управляемыми навигационными путями, которые не только облегчают использование, но даже способны шаг за шагом направлять пользователей между приложениями Business Objects в процессе анализа.

У нас Вы можете узнать о всех возможностях SAP Lumira, запросить цену или демонстрацию продукта

Источник

SAP Lumira 2.0 – Designer – Composites

SAP Lumira Designer – Composites

Composites can be considered as an “app within an app”. Composites are components, which are similar to SDK components, but composites can be created by an application designer itself.

Composites are available for usage only in the SAP Lumira Documents mode (A new preferred Start mode). A document can contain several composites. But a composite cannot be part of another composite.

A composites are reusable. Create a composite as part of one document and reuse in another document via referencing.

After launching the Lumira designer in the Lumira Documents Mode, in the Documents view (In case if it not found in your layout, go to View à Select Documents) there are 2 folders:

BI Platform Documents and Local documents

Step 1: Creation Of Composites

Under Local Documents create an application

Specify a name for the document E.g.: COMPOSITES_DOC

Now within the application create a composite, E.g.: LOGO

Step 2 : Composites- Interface Properties

Interface properties allow the users of your composite to configure their instances. These properties will be displayed in the Property sheet for a selected composite instance in an application

In the outline view, under Interface à Properties,

Right click and Create Property

In the property View fill the entries as shown

After which all the 5 properties are created –

Step 3: Binding of Composite Interface properties:

Add the shape component to the layout and assign a shape to this component from the additional properties

Now we can bind the interface properties created in the composite to the properties of the SHAPE component.

Go to the properties view of the SHAPE component, click on binding icon of the Line Color property

Select the interface property Line Color.

Similarly do the same for all other Shape component properties.

Step 4: Embedding a composite in an application

Create an application, say COMP_APP inside the lumira document COMPOSITES_DOC

The Shape component’s properties are set based on the values that we have defined in the interface properties.

Change values inside any of the interface property definition, and re-execute the application. It should be reflected in the Shape component.

In this way, we can control the values assigned to any of the property of the component via the interface properties.

Step 5: Creation of Events in the composite

It should also be possible to define events inside a composite.

The event which we have created now, would appear in the events section of the composite inside the app.(Go to the appà Layout àLOGO_1

In the On Click event of the Shape, write the following script

COMPOSITE.fireEvent(“My_onClick”);

Similarly create another event, say My_OnChange

Now add a switch component inside the composite and in the On Change Event of the switch, add the following script

Step 6: Usage of Interface events of the composites

Composite events allow the application designer to react to defined actions of this composite. This is the same as as an event for standard components like the On Click event of the Button component, for example. These events are exposed as an event property in the Property view of an instance of this composite.

In the My_OnClick add the following script

TEXT_1.setText(“The Logo is Microscope. It is an optical instrument used for viewing very small objects”);

and in My_OnChange Event add the script

TEXT_2.setText(“My OnChange Event has been Triggered”);

Now save the Composite and Application and execute it at runtime.

Step 7: Usage of Interface functions of the composites

Interface functions define the script functions of your composite.

In the composite’s outline view àFunction à Create Function My_Function,

Script the following for the

if ((SWITCH_1.isVisible() == true) ) <

Save and execute the application, click on the newly created button Appear/Disappear.

If the switch component inside the composite is visible, on clicking the button it becomes invisible and vice versa.

Step 8: Global Variables and Functions

Under the composite create a global Variable as shown

Now add a Check box to the Composite.

Create a global scripts Technical component and then a global script Change_Size

And add the following script to it

if (CHECKBOX_1.isChecked() == true) <

Text= ‘New Microscope’;

Now add a checkbox component to the composite and in the On click event of it call the global script GLOBAL_SCRIPTS_1.Change_Size();

Now execute the application and on checking the check box, the line size of the Shape component changes, and the tool tip changes from microscope to new microscope.

Step 9: Properties of composite

By default the above created composite is available under Composites

If you like to assign a custom group for your composite it can be done via

Now the composite is available under Mygroup

I hope this blog helps in better understanding of composites and its usage.

Источник

Lumira Data Access Extensions Step by Step

In version 1.17, SAP Lumira introduced an extensibility mechanism that allows developers to connect Lumira to new and non-traditional data sources: Data Access Extensions. The developer guide at help.sap.com/lumira is a great reference. To supplement that reference, this post will walk through the development of a simple but complete data access extension, step by step. Some programming experience is assumed.

The source code from this post is available at github. Most of the content is also available in webinar form thanks to SAP’s partner, Simba Technologies. The webinar includes a demo of MongoDB connectivity developed by Simba as a data access extension.

The Basics

Don’t worry, we won’t drown ourselves in abstract theory, but we do need to know a few basics to get started:

For the more visually oriented, here’s the above in diagram format:

Hello, World!

Let’s start by writing the equivalent of a “Hello, World!” program as a data access extension for Lumira. We’ll write it as a C# Windows Forms Application. You can write DAEs in any language provided the end result is a windows executable. After creating a new project in visual studio, this main function is generated:

We don’t need a user interface yet, so we’ll first hide the UI

Now all we have to do is write some CSV to the console in a way that Lumira will understand. Lumira expects you to write out two “blocks”. The first is called the DSInfo block, and it lists some configuration parameters that Lumira uses to interpret the data, such as the CSV delimeter character. This block starts with “beginDSInfo” on a line by itself and ends with “endDSInfo” on a line. Check the developer guide for a list of parameters that you can write between those tags. For now, we don’t need to pass any special configuration to Lumira, so our DSInfo block is written like this:

The second block that Lumira needs is the Data block. It too is surrounded by tags. Here’s how we write the “hello, world” data block:

Putting it all together, our complete main function is:

And that’s it! Now we need to build and test it.

Deploying Data Access Extensions

Although a DAE test utility is provided with Lumira ( C:\Program Files\SAP Lumira\Desktop\utilities\DAExtensions) and discussed in the developer guide, we’re going to test in Lumira itself. Let’s follow the happy path for now – assume that all of our code is correct – and I’ll put some debugging tips at the end of the post.

DAEs are not enabled by default with a new install of Lumira. They have to be turned on with a bit of configuration magic. To enable DAEs, open C:\Program Files\SAP Lumira\Desktop\SAPLumira.ini in a text editor and add these lines, as described in the developer guide:

Now we’ll copy our newly built DAE into the configured folder, and when we create a new document in Lumira, we select “External Datasource”

Clicking Next provides a list of all installed DAEs:

Our DAE is called “hello world” because the file name of the executable is “hello world.exe”. It is “uncategorized” because it was copied directly into the configured data access extensions folder. Had we placed it in a subfolder, the name of that subfolder would have been used as the category.

When we click Next, Lumira invokes the DAE and our program writes to the console before exiting. The result is this:

By default, Lumira assumes the first row of data contains the column names. This is configurable in the DSInfo block.

Next, let’s return some real data to Lumira. We’re going to use the Windows event log as our data source. Data Access Extensions can be written for all kinds of non-traditional, non-database data sources (as well as traditional ones) and the event log is convenient because all of us who run Lumira have one on our machines.

Writing Data to Lumira

First, let’s create a class that’s responsible for writing the event log to the console as CSV. We’ll call it EventLogWriter and start developing it in a top-down fashion, starting with a public Write() function and a couple of stubs for writing dsinfo and data.

It doesn’t do much yet, but it does motivate us to think about error handling. In its current form, WriteDSInfoBlock() would throw an exception when it was called from Write(), and we’re not yet communicating this failure to Lumira. We should strive to deliver meaningful, localized error messages when things go wrong, but for now we’ll settle for a simple, generic message. Error messages are returned to Lumira via stderr, as follows:

With basic error handling in place, let’s implement WriteDSInfoBlock(). Just as with “Hello, World”, it needs to start and end with beginDSInfo and endDSInfo tags. We’ll also, for illustrative purposes, be explicit about the fact that our first row contains column names:

And now we can implement WriteDataBlock(). It has to write the beginData and endData tags, with CSV data from the event log between them.

Although this does write the data in the CSV format, it’s a little too naive about the actual content of the event log. What would happen if one of the fields contained a comma, for example? Quotation marks also have a special meaning. And there might be null objects, which should be distinguished from empty strings. The rules for this are:

Let’s capture this logic in a function and call it before writing each field:

Now we’re writing the event log data to Lumira as CSV – let’s try it out!

After copying the extension exe into the configured extensions folder and creating a new document with it as a data source, we end up with the full content of the log in Lumira as a data set. We can now cleanse, mashup, and otherwise manipulate the data. Next time we refresh, those manipulations will be reapplied.

This is a good start. In many cases, though, we will want to allow the end user to provide some input that affects the query. For the event log data source, we’ll let them choose the number of rows to return.

Adding a User Interface

Our very simple prompt UI will look like this:

When the OK button is clicked, we’ll write the number of specified rows from the event log. Here’s an event handler for the OK button:

Pretty straightforward. We instantiate an EventLogWriter as before and then set a NumRows property using the value from the UI. After that, we simply close the application. Here are the updated portions of EventLogWriter:

We’ve added the NumRows property, initialized it with a default value (arbitrarily chosen), and then modified the loop in WriteDataBlock so that it will write no more than the specified number of rows. Lastly, now that we have a UI, we have to display it. Returning to our Main() function, we uncomment the line that displays the UI and comment out the line that creates an EventLogWriter:

This is a good time to test our work in Lumira. After selecting the event log data source, Lumira invokes our program and the UI appears.

After clicking OK, the extension sends data to Lumira and exits. If we look in the top-right of the New Dataset dialog, we see that the number of rows matches the number we selected:

This is as we intended, but actually not what Lumira wanted! This first screen in the data acquisition workflow is called “preview”, and its intended to allow the end user to sample the data before deciding whether to acquire the entire data set. With very large data sets, initial acquisition can take some time, and preview allows the user to sample the data before undertaking that process. When Lumira wants to preview the data, it notifies the extension of this fact by passing in some command line arguments. We’ll take a look at those momentarily.

Ignoring the preview problem for the time being, let’s click Create to finish data acquisition and see what happens.

The prompt appears a second time! Not what we want… Let’s fix it.

Parsing Command Line Arguments

For our extension program to understand what Lumira wants from it, it must inspect the command line arguments that Lumira gives it. We’ll implement the parsing of arguments in an “Args” class for use within the Main() function. The class will at first glance look more complex than it is, due to its length. Lumira’s input to extensions is very deterministic so we don’t need a lot of validation or error handling, but we do need to reconcile the way that command line arguments are understood by the system/OS with the way they are understood in our program.

When Lumira wants to preview data, for example, it could invoke our program like this:

Command line arguments are delimited by white space, so although we know when reading this that what Lumira means is that it is in preview mode (mode=preview) and wants us to return 300 rows (size=300), the system sees each of these arguments independently. We have to write a function, which we’ll call ParseCommandLineArgs(), to match keys with values and save them as properties that our program understands. We’re going to parse all four arguments that Lumira can pass now, and I’ll explain the ambiguously named “parameters” argument a little bit later.

We’re going to use Args to help with two things: deciding whether to display the UI and deciding how many rows to return to Lumira. Modifying our Main() function to use Args, we end up with this:

First, we use Args to parse the command line arguments. Next, we delegate instantiation of the EventLogWriter to a new factory function called “CreateEventLogWriter()”. Then, we decide whether to display a UI by calling the new function “UiRequired()”. Let’s look at CreateEventLogWriter() first:

It does the same thing that we did previously in our OK button click handler. Now we need this logic in more than one location, though, so it makes sense to move it to a factory function where it can be reused. Notice in the Main() function that we are now passing an EventLogWriter instance into the UI (“Form1”, the default name that the WinForm project generated). We have to use that instance instead of creating a new one. The UI code now looks like this:

OK, now let’s write some logic for deciding whether to display a UI. When Lumira is in preview mode, it will tell the extension how many rows (maximum) to return. When it’s refreshing, following a preview, it expects the extension to return the full data set. In the refresh case we will prompt the end user for the number of rows. This logic can be implemented as follows:

And with that, we’re again ready to test in Lumira. After creating a new document using the event log data source extension, we see the preview screen. It now shows 300 rows, which is the number specified by Lumira using a command line argument.

After previewing, click Create to acquire the full data set and Lumira will again invoke our extension, this time passing “refresh” as the mode argument. Our program detects this and displays a prompt to the end user.

Solving this problem requires us to look more closely at the DSInfo block and the “parameters” argument that Lumira passes to our extension.

Parameter Saving

Lumira calls the key,value pairs written into the DSInfo block “parameters”. The developer guide has a list of reserved parameters that Lumira understands. You can also write out your own parameters and Lumira will pass them back into your extension program each time it is invoked. This is a way to save small amounts of state. In our case, we’d like to remember the number of rows the user selected in between invocations. Let’s add this to the DSInfo block by modifying EventLogWriter.WriteDSInfoBlock():

On each line, write the name of a parameter, a semicolon, the value of the parameter, another semicolon and then a boolean value that appears to be ignored by Lumira at the moment. This extra “true” value is present in the examples in the developer guide, so we’ll add it in case it is used in the future. The number of rows is saved as the “num_rows” parameter.

When our extension starts, we have to read the num_rows value back in from the command line and set the EventLogWriter.NumRows property. Lumira passes parameters (a.k.a. the DSInfo block) back in as one big string following the “-params” argument, like this:

We’ll add a function to into EventLogWriter that parses the params:

The function takes as an argument the string that follows “-params” on the command line. We have already saved this string in the Args class and all we have to do is call ParseParameters() after instantiating the EventLogWriter. That will be done in our factory function:

When Lumira hasn’t specified the maximum number of rows via the size argument, we check whether there’s a num_rows parameter. If a num_rows parameter exists, it’s used to set the initial value of the EventLogWriter’s NumRows property. With that, we have handled the case of user-driven refresh. Now if we acquire 50,000 rows and then select Data-> Refresh document, the prompt that appears defaults to 50,000 rows. Much nicer!

Edit Workflow

● Add new columns that had been removed from the data source when it was originally acquired

● Remove columns that were included in the original data source

● Change values selected for SAP HANA variables and input parameters

On the last point about HANA variables/parameters – we can use it to change parameters for data access extensions as well.

When the edit workflow is triggered, instead of Lumira invoking the extension first with mode=preview and then with mode=refresh, it invokes the extension first with mode=edit and then with mode=refresh. Unfortunately, although edit mode is essentially equivalent to preview mode, Lumira doesn’t pass a size parameter in edit mode. Still, we will want to limit the data returned at this stage.

With our extension in its present state, invoking edit mode causes the extension to return to the edit/preview screen the full number of records that it returned during the last refresh. We will hard code a 300 row limit in edit mode because this is what Lumira normally asks for in preview. We also want to make sure that when the refresh occurs, the number of rows the user previously selected is the default value in the prompt UI (i.e. we don’t want the UI prompt to show 300 rows just because that’s our hard-coded edit/preview limit).

Let’s start by detecting edit mode and limiting the number of rows returned to 300. We’ll again modify our factory function:

Now, to prevent the prompt UI from showing 300 when it next appears, we separate the value of the DSInfo num_rows parameter from the EventLogWriter.NumRows property. By making these two distinct things, we can save a value for the num_rows parameter (the number of rows we want the UI to display next time), that differs from the number of rows being written this time.

To do this, we add a NumRowsParameter property to EventLogWriter that controls the value saved in the DSInfo. When the EventLogWriter restores its state by reading DSInfo, it will use the parameter value to set both the NumRows and NumRowsParameter properties. We can then set NumRows for the duration of this invocation without affecting the number of rows displayed in the prompt UI during next invocation. This isn’t elegant, but it’s a simple solution.

There’s one final change we need to make. When an end user changes the prompt value we want it be saved in the DSInfo. This means that EventLogWriter’s NumRowsParameter property has to be set. We must do this in our OK button click handler:

Now the edit workflow will be as desired. First, the extension is invoked with mode=edit and 300 rows are returned:

Next the extension is invoked with mode=refresh and the previous user input is remembered:

If you’ve been following along and writing the code yourself, you should now have the same code that was tagged “v0.7” in the git repository. Congratulations!

Debugging

A dialog appears showing all running processes. Select your extension by name.

Typically, your program will not wait for the debugger to attach and might even be finished running by the time you start the debugger. To get around this, make your program wait when it first starts. One way to do this is to display a (blocking) message box at the very beginning of the program. The program will wait for you to dismiss the dialog and you can use this time to attach the debugger:

And that, at last, is the end. Happy coding!

Источник