Managing GAM Repositories and GAM Applications in GX development time

This documentation is valid for:

The model design of GAM enables to connect to multiple Repositories to solve many scenarios where only one Repository wouldn't be enough. The connection to one Repository is done through a GAM Repository Connection, see HowTo: Get and Set GAM Repository Connections on how to set a GAM Repository Connection in runtime.

Besides, one Repository can have many GAM Applications (WEB GAM Applications and Client Applications (SD)).

Although only one WEB GAM Application Id can be specified per KB, many WEB GAM Applications can be defined in the same Repository (from different KBs).

So here we explain some scenarios where the same Repository is shared by different KBs, or different KBs use the same GAM database but different Repositories.

The possible scenarios are:

A. More than one KB. All of them use the same GAM database but different GAM Repositories.

In general in this case the KBs implement different solutions, and it may be from the same company.

It's an scenario where multiple Repositories can be used as a solution, taking into account the following:

All the applications which point to the same GAM database have to use the same GAM version, on the contrary this solution is not feasible.
There is an administrator who will manage all the Repositories (administrator of GAM Manager Repository).
The Repositories may have the same Repository Namespace in particular if you want that the users are shared between the Repositories. See Multiple Repositories Scenario: A company with different branches.
Each Repository will have its own administrator users, and the information of one Repository is not accesible from the other one unless the Repository Namespace is the same and the users are enabled in the other Repositories.

Steps to follow in prototyping time

Suppose application A is being developed and uses the same GAM data store as application B which is being developed from a different KB (they are different applications).

1. If GAM database was created from GeneXus IDE using application A, you have to define a Repository for application B.

See Howto: Create new Repositories.

2. In prototyping time, you need to specify in each GeneXus KB the following:

The same GAM data store properties (database name, user name, user password).

Figure 1.

After creating the Repository for application B, edit the properties of it, and get the Repository GUID, as shown in the following figure:

Figure 2.

Specify in Repository ID Environment property of KB "B" the Repository GUID obtained in the previous step.

Figure 3. Specify the corresponding Repository Id for the application of KB B (note that is the same as the one obtained when the Repository was created)

The Connection User and Administrator User are particular to each Repository, and are not shared to any other Repository.
Note that in KB "B" you need to specify the Connection User Name, Connection User Password, Administrator User Name, and Administrator User Password specified when the Repository was created.

Steps to follow in deploy time

Supposing both applications will point to the same GAM data store, the following will need to be done:

Create the Repositories in GAM as explained in Howto: Create new Repositories. The Repository Namespaces should be different so there's no information shared between Repositories.
Create the connection.gam for each application, using GAMDeployTool, see GAMDeployTool:Creating connection.gam file.
Copy connection.gam file under the virtual directory (or under the web app in case of java). Each connection.gam file points to a different GAM Repository Connection.
Copy application.gam file under the virtual directory (or under the web app in case of java). Each one references the corresponding Application Id of each application.
Check that the client.cfg, web.config, or gxconfig.yaml files of each application (depending on the GeneXus generator used) point to the same "GAM" data store.

Note that if connection.gam file has only one entry (as is enough in this case), pointing to the GAM Repository Connection which corresponds to the application, the user will be connected directly to this Repository, without the need to code anything particular.

B. More than one KBs. All of them use the same GAM database and the same Repository, but register different GAM Applications in GAM DB.

This scenario is such that the web applications (of the same company in general) are different applications but are modules of the same enterprise application (for instance purchases and sales).

In this case you should:

Specify the same GAM data store properties (database name, user name, user password) for both KBs.
Specify the same Repository ID Environment property value for both KBs.
Specify a different Application Id property in each KB. Each Application will be registered independently in the Repository. Take into account that one physical web app only references one WEB GAM Application (referenced in application.gam file) so the applications will have to be installed in different web apps each pointing to its corresponding Application Id in the Repository.
Set the Connection User and Administrator User accordingly; you can create different users or share them.
In case of SD Applications, each GAM Client Application will be registered independently in the corresponding GAM Repository of the KB.

In deploy time:

The client.cfg, web.config, or gxconfig.yaml files of each application (depending on the GeneXus generator used) pointing to the same "GAM" data store.
connection.gam file under the virtual directory (or under the web app in case of java) pointing to the a GAM Repository Connection of the same Repository (it can be a different GAM Repository Connection for security reasons).
application.gam file under the virtual directory (or under the web app in case of java) referencing a different Application Id (the one corresponding to the KB of the application).