Skip to Content
Author's profile photo David Stocker

Lumira 2.0 Designer Highlights – Composites (part 1)

If you create a story in SAP Lumira 2.0 Discovery, then open that same document in SAP Lumira 2.0 Designer and create a new application, you may notice something.  The story that you created in Discovery is available in the Components palette.

Yes, the story that you created in Discovery is available as a “component” and you can drop it right into the app.

You might notice something else too.  If you drop that story into one or more apps and then later on you alter the story inside of Discovery, the app(s) will use the updated version of the story when they are opened next.  Additionally, you might have notice when you created the app in Designer, that that you had the option to create something called a “Composite” and that if you do create one, its icon in the document browser is the same as a story.

What is a composite?  To answer that most concisely, I should point out that during the initial development phase, before we go around to officially naming the feature, the architects were calling it “app-in-app”.  Effectively, composites are modular, reusable “app” blocks that can be plugged into other apps.  When these apps are called by the user, the app is dynamically assembled, using the newest version of any composites in it.  This opens up two new app management techniques that were not possible in the old Design Studio 1.x.


Write Once, re-use Repeatedly

Suppose you have a large portfolio of apps, but there are certain things that you do over and over.  Perhaps your company uses a standard app header, with a logo, in every app.  In the past, you might have copied and pasted this header into every new app, or if you were feeling clever, you might have created a template with the header.  But what happens when the logo changes?  Changing the template does not retroactively alter all of the apps in your landscape, so you still had to manually edit each and every one.


With composites, this is no longer the case.  You create your header once, as a composite and add that as a component to each and every app.  Then when the powers that be decide that a new logo is needed, you edit the logo in one place, the composite, and you are done.  The change automatically takes effect everywhere!


Headers, footers, standard dialogs, custom KPI tiles, etc. etc.  You can now keep a catalog of custom document parts, re-use them wherever needed and updates are handled automatically.


Collaborative Development

Another use case that often comes up among customers is when particular apps are large, complex and built by multiple people.  In the old 1.x, it was not possible (out of the box) to have multiple developers working on an app in parallel.  Some customers did create an infrastructure that could dynamically assemble .biapp files from constituent parts and while we were impressed by these scenarios, they were never standard, supported scenarios and the customer was effectively on their own.


With 2.0, you can break the apps up into composites.  As each developer updates the part that she is working on, the changes take effect in the main app.  It is simple, uses standard tools, requires no voodoo and is supported.


Now we understand what composites are and what they are good for.  Next time, we’ll build a simple composite and make use of it.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Put things right once and for all

      Author's profile photo Martin Stillnerus
      Martin Stillnerus

      Hi David,

      Thank you for your Lumira Posts. Highly appreciated! We have just started our Lumira 2.x upgrade project from 1.6 and are reading up on best approach. We have a lot of DS-applications and almost 90 % of them are published in the InfoView portal having the same layout. The only difference is the data source assignment. If we want to add/modify something we must open and change all DS-applications. Basis for this customer specific application template has been the "generic analysis template" with customer modifications and a customer specific global CSS.

      I am coming from the BW Bex world where we used to publish the query in the portal that got executed by the standard web template. A change in the standard template had impact on all published queries. If I understand this correct, we will now be able to do so now with composites.

      My question to you is, would you recommend building a composite that has all the functionality corresponding to the generic analysis template (or perhaps Basic analysis layout), including all technical components such as scripts, export settings and so on? Is it even technically possible to add technical components into composites?

      My purpose is to be able to change once and deploy to all my 90 % applications in one go, since they are intended to have exactly the same layout and functionality except for the assigned data source.

      Author's profile photo Gabriel Motor
      Gabriel Motor

      Hi Martin,

      I have exactly the same question. We have around about 500 Reports.

      Did you get a answer for you question?





      Author's profile photo Martin Stillnerus
      Martin Stillnerus

      Hi Gabriel,

      take a look at Mustafas answer.