Create application/service group

Use groups to define aliases for directories where application configuration files can be stored.

A GROUP element consists of an alias (Id) and a directory (path) to where the groups' applications or services are found. You can use groups to organize your applications and services into logical groups or a hierarchy. For example, consider this URL:

http://server/gas/ua/r/accounting/app1

In this URL, both a group (accounting) and an application name (app1) are specified. The GAS, on receiving this application request, uses the accounting group alias to identify the directory holding the external application configuration file:
<GROUP Id="accounting">/path/config/accounting</GROUP>
In this directory, the GAS expects to find a file whose name matches the name of the application with an xcf suffix. For this example, the GAS looks for a file named app1.xcf.

Where to define groups

Groups can be defined in:
  • XML files
  • The GAS configuration file, as.xcf.
Examples for both methods are given in the sections below. It is recommended that you define groups for your applications and services in XML files instead of in the as.xcf, so as to keep your configurations when you upgrade the GAS installation.

Both as.xcf and XML file group configurations can be used simultaneously but be aware that duplicate group ids, wherever they are defined, will generate an error and stop the dispatcher.

Default groups in the as.xcf file

The GAS configuration file (as.xcf) provides default groups for applications and services, defined using the alias name _default. 
<APPLICATION_LIST>
   <!-- default group for external applications -->
  <GROUP Id="_default">$(res.path.app)</GROUP>
  #...
</APPLICATION_LIST>
And for services:
<SERVICE_LIST>
   <!-- default group for external services -->
  <GROUP Id="_default">$(res.path.services)</GROUP>
  #...
</SERVICE_LIST>

If an application or service configuration file does not specify a group, the _default group is used and the application URL can omit using a group name and simply reference the application. For example, consider this URL:

http://server/gas/ua/r/Edit
The application URL does not specify a group, and the Edit application is not defined internally. It must therefore be defined in an external application configuration file, located in the directory defined for the _default alias – the resource $(res.path.app), which resolves to appdata/app directory (On Linux/UNIX: $FGLASDIR/appdata/app, on Windows®: C:\ProgramData\FourJs\gas\gas_version\app).

In this directory, you would expect to find Edit.xcf, the Edit application's configuration file.

Define custom groups in the as.xcf file

Example 1: "accounting" group defined in as.xcf by path to directory

<APPLICATION_LIST>
 #...
  <GROUP Id="_default">$(res.path.app)</GROUP>
  <GROUP Id="accounting">/myapps/accounting</GROUP>
 #...
</APPLICATION_LIST>

To access an application that has its configuration file stored in the accounting group directory, enter an application URL that includes the group alias in its path: http://server/gas/ua/r/accounting/app1. Based on this URL, the GAS finds the configuration file app1.xcf in the directory specified for the accounting group.

Example 2: "demo" group defined in as.xcf by reference to resource

<APPLICATION_LIST>
 #...
  <GROUP Id="_default">$(res.path.app)</GROUP>
  <GROUP Id="accounting">/myapps/accounting</GROUP>
  <GROUP Id="demo">$(res.path.demo.app)</GROUP>
 #...
</APPLICATION_LIST>

This example assigns the alias demo to the directory containing the external application configuration files for demo applications. The path is defined using the resource $(res.path.demo.app). By wisely using a resource, a change to the directory structure only requires a change to a single RESOURCE element in the configuration file.

To access an application that has its configuration file stored in the group directory, enter an application URL that includes the group alias in its path: http://server/gas/ua/r/demo/CardStep1

Based on this URL, the GAS would expect to find the configuration file CardStep1.xcf within the directory specified for the demo group.

Define groups in XML files

This is the preferred method for defining groups for applications and services. Separate XML files must be used for applications and services.
  • Application group XML files must be formatted with a root node named APPLICATION_GROUPS containing a list of one or more GROUP (for an application) nodes, each GROUP node similar to GROUP nodes that can be present in the APPLICATION_LIST in the as.xcf.
  • Service group XML files must be formatted with a root node named SERVICE_GROUPS containing a list of one or more GROUP (for a service) nodes, each GROUP node similar to GROUP nodes that can be present in the SERVICE_LIST nodes in the as.xcf.

Groups defined in XML files will behave the same as GROUP defined under the APPLICATION_LIST and SERVICE_LIST nodes in the as.xcf for all purposes except the gasadmin gar --list-archives command, which will not show applications and services from the service-group/application-group files.

The examples below show well-formed XML files with configurations for application and service groups.

Example: application group XML file

An application group XML file could look like this:
<!-- myApp_group.xml -->
<APPLICATION_GROUPS>
  <GROUP Id="group_one">/myapps/group_1</GROUP>
  <GROUP Id="group_two">$(res.path.app)/group_2</GROUP>
</APPLICATION_GROUPS>

Example: service group XML file

A service group XML file could look like this:
<!-- myService_group.xml -->
<SERVICE_GROUPS>
  <GROUP Id="group_one">/myservices/group_1</GROUP>
  <GROUP Id="group_two">$(res.path.services)/group_2</GROUP>
</SERVICE_GROUPS>
The XML files can be loaded at the command line when starting the dispatcher with the --application-group and --service-group options. These options can be specified only once:
httpdispatch --application-group myApp_group.xml --service-group myService_group.xml