Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert

In Q2 2024, SAP Build Work Zone, advanced edition released the support of role-based access to UI Integration Cards. While bringing increased flexibility of workpages (by allowing cards to be automatically filtered according to user's roles), that also is a significant step forward into a unified content model of cards, apps, and roles. Card is no longer a standalone entity, but is now always a visualization of an App (short for "Business Application"), which in turn can be assigned to Roles for access control and dynamic filtering features. However, with those shifts on concepts and features, previous ways of card management has been changed as well.

Change #1: Upload Card button has disappeared from Admin Console

Upload Card button is removedUpload Card button is removed

By disallowing a card to be uploaded directly and used standalone, we now make sure there is always an app which the cards belong to. And with role assignments to the app, the card can then have role-based access control.

Change #2: Card creation/deletion is managed by App from the Content Manager

Because of that change, all the existing cards which were uploaded directly to Work Zone will now be migrated to become visualizations of some apps. That's why you will see a list of new local apps showing up in the Content Manager. They have the same title as their card visualization.

local apps created out of the cardslocal apps created out of the cards

And if you want to delete a particular card, you can no longer do so on the Admin Console UI, but must delete its app on the Content Manager UI.

Delete option is goneDelete option is gone

Here's the step-by-step guide illustrating the complete flow of the new way of card management: Of course, that might appear to be a lot of unnecessary effort in addition, if all you want is to deploy a card and use it as before. But what comes along is the additional capability on access control for cards based on the roles. This additional layer between roles and cards also makes it possible to decouple the permission definitions with the actual controlled entities. That is, an app could at any time be updated to host a new card as its visualization, with all role-assignments, navigation target, and app-level settings unchanged; a card could also point to a dynamic navigation target controlled by its app. In the future, it will even be possible for one app to have multiple visualizations, e.g. several different tiles and cards belonging to one app. That would be a common case for several cards inside the same content package, where they all link to the same target system (only differ in relative paths or URL params) and are supposed to be exposed to the same group of users, thus no need to repeat the configurations for each card.

What happened exactly during the card migration?

A migration will be run for all existing Work Zone customers, during which a local app will be automatically created for each card, configured to take the card as its visualization. And the wrapping app's id is always set to "<card_id>.app", with title and description set to the same with the card. Once migrated, the wrapping app will be assigned the Everyone role, so that the card is still exposed to all end users as today (of course, the restrictions defined in Card Access List will continue to work on top). Later, if customer wants, the admin could change the role assignment of the app to restrict the card's access to a smaller group of users who have the corresponding roles.

What can go wrong and what to do in case of failures?

However, there are a few cases, although rare, that might result in failure during the creation of the wrapping app or the association between the card and its wrapping app. The most likely causes are:

  • Card id is longer than 166 characters (because there's a limitation of 170 for App id)
  • Special characters (such as "-->") in Title or Description

When such unfortunate situation does happen, the wrapping app will not be created. But don't worry, the failed cards will continue to work as before. The delete option will still be there for such cards. And you can tell whether there are any failures by checking if the delete option still exists for any cards or by checking if any cards don't have a corresponding app (with the same title) listed in the content manager.

Delete option is still there for failed cardsDelete option is still there for failed cards

You can delete such a card directly from the Admin Console UI, and then try checking and fixing the problems and creating a new local app with the card uploaded as visualization. If you still encounter failure and can't figure out the root cause, please do not hesitate to contact SAP support by filing an incident ticket.