Hello everyone!

Lately I get asked a lot which project I am currently working on at our Product Innovation department. I tell them I am working on moving the roles out of our Intelligent Application Manager (IAM) into the Software Factory. Most of the times they nod slowly and say “Right!”. Let me begin by clarifying that by saying roles, I actually mean the configuration of roles and their corresponding model rights. However, you can imagine that some extra explanation is still required. Roles are already an important working part of IAM. Why would we want to move them to the Software Factory?

It is mainly because of the importance of these roles that we have decided to move them. We consider them as an important part of the model, which is the domain of the developer. Since the model belongs in the Software Factory, why not also the corresponding role rights? In our opinion moving the roles to the Software Factory is the next logical step to take the concept of Role Based Access Control to the next level. For more information regarding this topic, you can visit the blog The Role of Zombies.

Moving the roles to the Software Factory also provides a lot of new possibilities. Hence, this blog post: Roles in SF - Considerations and possibilities.

Considerations

Moving the roles

What is striking now about roles, is that they are addressed quite late in the development process. When you have developed a new table, it may take some weeks before you can configure the corresponding role rights. After all, you have to synchronize to IAM first. By that time there is a very good chance you no longer have focus on the table you have developed. You may have to rethink again what its main purpose is, and which roles should have access to it. This not only goes for this particular table, but for all affected model objects.

How great would it be if we could configure the roles at a much earlier stage than currently is the case? That is exactly what we have tried to achieve by moving the roles from IAM to the Software Factory. This means that the configuration of roles will be placed with the developer, instead of the application manager. This makes it possible that, during development of one or more model objects, you can already consider which roles should have rights to them. Thus, leading to a more process-oriented development process. Since the rights are managed in the Software Factory, they can be tested there and optionally pass through an all DTAP-environments. This means there is a much smaller chance that mistakes regarding the configuration of roles end up in production.

From now on, the application manager in IAM will get the roles with the model. This way he or she can keep the focus on linking users to the user groups, and linking user groups to the roles. A blog related to our vision of the Future of IAM will follow later.

Benefits

There are a number of additional benefits that have led us to move the roles:

• Since roles are now part of the model, they are also a part of branching and merging.
• From now on the role rights remain intact when a model object is renamed. No need for conversion scripts anymore!
• Roles can be validated and tested. To help you on your way, we have already added a couple of validations. More role based validations will follow in future versions of the platform.
• It is now possible to configure (parts of) roles with the dynamic model.
• It becomes easier to deliver modules from the Software Factory to our customers or System Integrators.

Possibilities

To support you as good as possible in the process of configuring roles, the Software Factory offers the following functionality.

Access control

To accommodate the rights functionality, we have created a new menu group in the Software Factory: Access control. This menu group contains the same two screens you were used to in IAM: Roles and Model rights. Attention has been paid to a screen that makes better use of the available space, and that reduces the number of nested tab pages.

In the Roles screen it is possible to configure the role rights by approaching it from a single role in the list. Also the roles themselves can be arranged here. We have of course ensured that the current roles and rights in IAM are not lost. To this end, a task is provided to import the existing IAM roles into the Software Factory. Although all roles are imported with the existing configuration, this could be a great opportunity for you to Redesign your roles. A blog related to this topic will follow later.

In the Model rights screen it is possible to configure the role rights by approaching it from a model point of view. It remains possible to go to the New objects tab page, just like in IAM. This tab page contains a task to navigate to the corresponding model object, so it can be configured.

Role simulation and other personal settings

Just like the roles, the synchronization to IAM has also been moved to the Software Factory. More information regarding this topic will follow in a blog post in the near future.

Before synchronizing, every role can be tested by a developer individually by using the role simulation setting. A developer can enable role simulation by going to Runtime configurations in the Deployment menu group to set the role simulation for the currently active project version.

Role simulations across all project versions for users can be found and updated by going to Users in the Settings menu group. The runtime configurations have three personal settings that can be configured: ­Active, Sequence no and Simulate role.

The Simulate role setting will enable role simulation if filled. Only one role can be simulated at a time. Due to limitations with the current generation of user interfaces, changing the Simulate role setting will affect all runtime configurations of the project version for this user. This will be resolved in a future version.

The Active setting determines whether or not the runtime configuration is available in Indicium for this user and should be enabled when using Universal, Windows on Indicium or Mobile.

The Sequence no setting only has effect when using Universal. This setting determines the order in which runtime configurations are shown as applications in the menu. This setting is only relevant when Universal is running against a Software Factory without providing a specific runtime configuration.