Interoperability between Lumira Discovery & Designer - How to deal with custom extensions?
Dear customers and partners, Designer enthusiasts and Discovery fellows,
One usage scenario that SAP likes to point out for Lumira Discovery is the so often mentioned “interoperability” between Lumira Discovery and Lumira Designer.
The business perspective
The idea is to enable business users to “draft” a report that they would like to see. They can add data sources, define info charts & tables and even create a visual design. Lumira Discovery is the tool of their choice for this task.
Then, they send the report over to the IT guys, who can check the report and enhance it by additional functions and scripts. They will use Lumira Designer for this task. These can be general features that were agreed upon to be included in every SAP report. Or additional features such as our Export extension.
The tech perspective
Now, let’s have a look on “interoperability” from the technical perspective:
This means a report can be opened in both Lumira Discovery and Lumira Designer. This is only possible, though, if components of the report are available in both tools. This is actually the reason why SAP spent a lot of effort to bring both tools on the same platform.
The extension perspective
Now, extensions enter the game. Extensions are always very useful – just to name two of them: IBCS charts and tables by www.graphomate.com and, of course I have to name it here, our biExport extension for extended export to PowerPoint, Word, PDF and Excel.
Unfortunately, SAP has not yet brought extensions for Lumira Designer and Lumira Discovery on the same platform. Instead, two absolutely distinct types of extensions are provided:
- SDK Components: Lumira Designer only, but do support scripting and offer a wide range of features
- CVOM Extensions: Available in both Lumira Discovery and Lumira Designer, but pure visualization, no scripting
Now you say, if CVOM Extensions can be used in both tools, where is the problem?
Well, you are right if your extensions are really simple and you do not use any scripting. But frankly, I have never seen any productive Design Studio application without scrips. Noone just uses components and extensions statically. Already to control some behaviour of a component with the click of a button, you have to use scripting …
The best practice
So how should we deal with the distinct extension types?
Let me explain the recommended best practice with the example of our biExport extension:
- We offer a small CVOM extension in Lumira Discovery, which enables users to create one-click exports of their storyboard
- We offer a fully customizable, fully scriptable, fully scalable SDK component in Lumira Designer, which enables the IT guys to fulfil even the most complex and most special requirement of business.
We would have liked to have the SDK component framework also in Lumira Discovery, as we have already designed the biExport solution to be fully scalable: Easy to use for beginners, but also capable of customization to the detail. This is not at all possible with the CVOM extensions.
So, as we now have two different extenstions, how should we deal with interoperability?
Our recommendation to our customers is the following:
- Provide Lumira Discovery users with the CVOM component for direct exports
- In Lumira Designer configure a composite, which defines the general standard properties for the export SDK component
- If a Lumira Discovery user requests enhancements to a “draft” report, simply add the export composite to the Lumira Designer application
- Publish the application to make the enhanced export available to the Discovery user.
Still, we are hoping SAP will enable SDK components in Lumira Discovery soon.
Looking forward to your experiences with extensions and interoperability!