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.
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.
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.
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.
- SAP Managed Tags:
4 Comments
