Hi,

Due to some limitations in RAF I have written a new alternative GUI, that offers more flexibility when it comes to security and dynamic projects.

Its in alpha state, so more testing has to be done to make it production ready, but concept is working.

If someone is intrested I can share a war file with you to test.

1         OperGui

OperGui is an alternative GUI for RAF, targeting operational personal.

1.1       Why a new GUI to RAF?

In RAF plans are mainly related to CELL’s wich makes it clumsy an forces you to duplicate a lot of the common tasks automated with a project.

RAF also has a bad security implementation, IBM has tried to go around this by forcing you to attaché all projects to a CELL.

RAF do not offer dynamic forms that is populated by selecting an area or with external data.

2         Concept of OperGui

OperGUI addresses the limitations in RAF in a more elegant and flexible way.

2.1       Security model

It is common that users has different access right in production, Quality Assurance, Test, Development environments.

So some projects a user are allowed to run in test are not allowed in production, or more clearly the group of people allowed an action is ENV_TYPE specific.

ENV_TYPE == PROD,QA,TEST,DEV

e.g. the usage of the CELL, is it a PROD cell or a TEST cell

A User also has a role, but the role might be different depending on the CELL (ENV_TYPE of the CELL), a user might be able to deploy applications in TEST cells but only check application run status in PROD cells.

A users access level is defined with accessgroups.

One ENVIRONMENT (a group of cells representing the lifecycle for an application, containing DEV,TEST,QA and PROD cells) is allowed to group projects into following roles;

Admin, Deployer, Operator, Monitor

Users are then grouped into access groups based on the number of roles used, the roles are generic and overided by a specific if one exist.

Example;

MONITOR

OPER

DEPLOYER

ADMIN

PROD_ADMIN

Members of ADMIN are allowed ADMIN role to all ENV_TYPE cells that are not classified as PROD

So minimum 4 access groups has to be defined.

Access groups are inheriting each other.

The CELLs access group is attached to the lovest level access group that users should have to access this cell.

So based on that we only have the example above, all PROD cells have the access group PROD_ADMIN, and all non PROD cells has the access group MONITOR

2.2       Projects

Projects are tied to an access group.

Normaly all projects are attached to one of the base access groups MONITOR,OPERATOR,DEPLOYER,ADMIN but can also be attached to an ENV_TYPE specific access group.

2.3       Execution rights on a project

Before execution is allowed the projects access group are checked.

If project access group is ADMIN and the CELL ENV_TYPE is PROD and if there exists an access group named PROD_ADMIN, user has to be member of the PROD_ADMIN group to access the project.

2.4       Required variables in project

Environment variable attached to a project has to contain following variable entrys, and we recommend that they are set to hidden to prevent editing, readonly do not work;

2.5       Project naming convention

Project has to follow our naming convention to be visible in opergui we allow generic project based on ITEM_TYPE, this project can be overided by ENVIRONMENT specific version of the project;

<ENVIRONMENT>_<ITEM_TYPE>_projectName

<CELL_TYPE>_<ITEM_TYPE>_projectName

Second is overided by first, an example of this ;

star_SERVER_stop (ENVIRONMENT star specific version of server stop project>

WAS_BASE_SERVER_stop (generic server stop script for websphere BASE servers>

WAS_ND_SERVER_stop (generic server stop script for websphere ND servers)