Setting up the Design environment

With IBM Financial Services Workbench 2.0, the Solution Designer gives the flexibility to connect to one or many Git Providers. Using these Git Providers, one has the possibility to decide with every solution, where the modeled data and the implemented code should be stored. The permissions that are defined at the Git Provider will be automatically applied to the Solution Designer and therefore full control over the available capabilities for the users is guaranteed.

Manage Git Providers

Admin users can manage the available Git Providers in the `Admin Settings` area. Before creating a solution, the Git Provider has to be defined there. Each Git Provider is identified by an unique alias.

The supported Git Provider types are:

  • Gitlab (self managed)
  • Bitbucket Server

Use Git Providers

To use a Git Provider, every user has to define an access token for the Git. All supported Git Providers provide the possibility to create these personalized access tokens. Each user can only specify one token per provider. This token will be from then on used for every interaction with the remote Git and also to restrict the capabilities of the user to the permissions that are set in the remote Git repository.

Use multiple Git Providers

If solutions should be stored at different places, an Admin user can define multiple Git endpoints. While creating a solution, the creator could define, where the solution should be stored. Also, a specific group could be specified while creation. These groups are usually used, to restrict permissions on certain solutions for dedicated users.

Manage Git Providers

In order to create and manage Git providers you must have Admin priviliges. To access the Admin Settings page use the Settings capability on the top right of the page. There you will get an overview of the already existing Git providers and their master data.

Create Git provider

To create a new Git provider use the Create capability.

The master data of a Git provider are the following:

Property Description
Alias Used to specify a Git provider under the given alias name.

This field is mandatory.
Type This is the Git provider platform. There are two options: Gitlab and Bitbucket.

This field is mandatory.
Base URL The URL to the Git provider. This value must be unique.

This field is mandatory.
Label This is a short description of the Git provider.

This field is optional.
Delete Git provider

To delete a Git provider use the header or inline Delete capability. After confirming the action, the Git provider and all tokens related to it will be permanately deleted.

Attention: You are not allowed to delete a Git provider if there are still soluitons in the Solution Designer associated to the specific provider.

Necessary Git Token permissions

The available capabilities in the Solution Designer depend on the permissions that are assigned to the user in the remote Git.

Grant general permissions for users on repositories

Repository or group administrators on the remote Git are responsible to grant access permissions on the repositories for the actual users.

  • GitLab
    • To create new solutions: at least maintainer permissions on the group must be granted.
    • To edit the solution content: at least developer permission (on the group or the repository) must be granted.
    • To view the solution: at least guest or reporter permission (on the group or the repository) must be granted.
    • To delete a solution: at least owner permission on the group must be granted.
      Attention: The above described permissions are valid for a GitLab default setup. If an installation has additionally specific restrictions on the repositories and groups, the granted permissions might have to be different.
  • Bitbucket Server
    • To create new solutions: administrator permission on project must be granted.
    • To edit the solution content: at least write permission (on the project or the repository) must be granted.

    • To view the solution: at least read permission (on the project or the repository) must be granted.

    • To delete a solution: administrator permission on project or repository must be granted.
      Attention: The above described permissions are valid for a Bitbucket default setup. If an installation has additionally specific restrictions on the repositories and groups, the granted permissions might have to be different.

Define specific permissions on tokens while generation

Usually, one could explicitly define the basic permissions for the token while creating the token in the remote Git Provider.

Minimum permissions that need to be granted for the token:

  • GitLab
    • Select scope `api`
    • Select scope `read_repository`
    • Select scope `write_repository`
  • Bitbucket Server
    • Select permission “Read” for basic read access
    • Select permission “Write” to allow create, delete and edit capabilities, as well as commiting to the repository
    • Select permission “Administrator” to allow create, import and delete solutions

Manage User settings

To access the User Settings use the Profile capability on the top right side of the page and navigate to the User Settings page.

Create a Git token

Each user can have one token for each Git provider for which he has rights. To create a new token use the header capability Create in the Git tokens tab on the User Settings page.

A Git token is defined using the following master data:

Property Description
Token name

Name of the token. It is unique for each user.

This field is mandatory.
Git provider It is a list of all the Git providers to which the current user has rights. The Git providers are represented with their assigned Alias that was provided by the Admin user.

This field is mandatory.
Access token This is the actual Git token.

This field is mandatory.
Git provider username

This is the user name as defined in the Git provider.

This field is madatory.

Delete a git token

To delete a Git token use the inline or header Delete capability. After you confirm the action the Git token will be permanately deleted.