Packaging Open-Xchange Application

The Open-Xchange Hosting Edition is built in a completely modular way that allows service providers to offer a variety of Smart Collaboration solutions - from business e-mail over personal information management (PIM) to a comprehensive collaboration solution. The architecture of the Open-Xchange Hosting Edition enables seamless integration into existing infrastructures with existing tools for authentication, user setup, system administration, accounting and e-mail storage. The Open-Xchange Hosting Edition offers a complete client capability that makes it possible to operate many thousands of customers simultaneously in a virtual server environment. This guarantees customers consistently good efficiency and performance and utilizes hardware resources in the best possible way.

Note: above information is taken from application vendor home page.

Listed below are the sections of an APP-META.xml file supplied with your package:

Type of environment. The application vendor states that Open-Xchange can seamlessly integrate to any environment. So, we can draw a conclusion that the application is a multi-instance one and may be provisioned to external environment that is not managed by a Controller.
Model of service provisioning. The application may serve to some number of customers simultaneously in a virtual server environment. Each customer can work in his own environment within this instance – completely separated from each other customer.
Services hierarchy. Open-Xchange supports multi-tenancy and this means that customers (tenants) are enabled within one application instance. Within each tenant (organization) a number of end-users (staff members) is created. In order to inform the Controller about service destination we assign class attribute to each service. Let's write down it in the Specification terms:
```
<service id="context" class="service">
```
```
  <service id="account" class="account">
```
```
  </service>
```
```
</service>
```

Used technologies. There is no need to provision application itself, so the only requirements we should declare are script language support and mail box for end-users. Let's write down it in the Specification terms:

<service id="context" class="service">

 <requirements xmlns:php="http://apstandard.com/ns/1/php">

  <php:version min="5.0" />

  <php:extension>soap</php:extension>

 </requirements>

 <service id="account" class="account">

  <requirements xmlns:mail="http://apstandard.com/ns/1/mail">

   <mail:mailbox>

    <mail:id>account</mail:id>

    <mail:access>

    <mail:imap/>

    </mail:access>

    <mail:outgoing>

<mail:smtp/>

    </mail:outgoing>

   </mail:mailbox>

  </requirements>

 </service>

</service>

Presentation details and settings. We defined earlier that there are two services - tenant environment and end-user account. Tenant environment requires the following settings on installation: 'administrator login and password, and profile information. The second-level service - account - requires user login, password and profile information. When end-user logs in application it is necessary to provide tenant credentials along with user ones. Therefore, we have to hide tenant's credentials from the user. APS allows assigning the class attribute to a setting or a setting group. This attribute informs Controller about the setting purpose. The Controller may decide whether to prompt customer or use some pre-defined values, basing on attribute meaning. Let's group these settings for better presentation, and write down it in the Specification terms. Here, we demonstrate only tenant settings. to view the whole set, refer to the Appendix C. Open-Xchange Sample Metadata section.

<service id="context" class="service">

 <settings>

  <group class="authn">

   <setting id="admin_login" class="login"

            type="email" installation-only="true"

            default-value="admin">

    <name>Administrator login</name>

   </setting>

   <setting id="admin_password" class="password"

            type="password" track-old-value="true"

            min-length="1">

    <name>Administrator password</name>

   </setting>

  </group>

  <group class="vcard">

   <group class="email">

    <setting id="admin_email" class="value" type="email">

     <name>Administrator primary email address</name>

    </setting>

   </group>

   <group class="fn n">

    <setting id="admin_given_name" class="given-name" type="string"

             min-length="1">

     <name>Administrator given name</name>

    </setting>

    <setting id="admin_surname"

             class="family-name" type="string"

             min-length="1">

     <name>Administrator surname</name>

    </setting>

   </group>

    <setting id="organization_name" class="organization-name"

            default-value="" type="hidden">

     <name>Organization</name>

    </setting>

  </group>

  <setting id="filestore_quota" type="hidden"

           default-value="1024">

   <name>Open-Xchange context wide filestore quota (in MB)

   </name>

  </setting>

 </settings>

</service>

Open-Xchange comes in three editions - each with a specific set of features. Having a provisioned application, a tenant may select either edition for any specific user, whereas the user must not have such option. To make this possible, the service of account class must have a special hidden setting. The setting value will determine the edition of Open-Xchange enabled for a specific user.

<service id="account" class="account">

<setting id="ox_module_access" type="string" visibility="hidden" default-value="groupware">

	<name>Open-Xchange administrator access level</name>

		<description>

		This is access level of Open-Xchange context administrator account.

		Valid values are 'webmail_plus', 'pim_plus', 'groupware',

		or any other defined in ModuleAccessDefinitions.properties file.

		</description>

</setting>

</service>

Content delivery method. Open-Xchange integrates into existing infrastructures by itself. So, it is provisioned like external service. When Controller provisions external services, it need to know service installation host, DNS name or IP address and login credentials. These settings affects for all instances of services and should be set prior to any service provisioning. Such settings are application global settings. Let's write down it in the Specification terms:

<global-settings>

 <setting id="ox_host" class="title" type="string"

          default-value="" min-length="1">

  <name>Open-Xchange installation host</name>

  <description>This is DNS name or IP address of

               Open-Xchange installation, used for

               provisioning access.

  </description>

 </setting>

 <setting id="ox_site" class="title" type="string"

          default-value="" min-length="1">

  <name>Open-Xchange public site address</name>

  <description>This is DNS name or IP address of

               Open-Xchange public site address.

  </description>

 </setting>

 <setting id="ox_master_admin" class="title" type="string" installation-only="true" uniq="global">

  <name>Master Administrator Login</name>

  <error-message>Please make sure the text you entered

                 starts with a letter and continues

                 with either numbers, letters,

                 underscores or hyphens.

  </error-message>

 </setting>

 <setting id="ox_master_password" class="title" type="password">

  <name>Master Administrator Password</name>

</setting>

</global-settings>

Note the ox_master_admin has a uniq attribute which indicates that the unicity of this value is ensured by the Controller. This attribute may have the following values defining the scope of unicity:

global - the setting value should be unique for all application instances provisioned in all global contexts.
application - the setting value should be unique for all application instances provisioned in the global context.
owner - the setting value should be unique for all application instances of the customer.
service - the setting value should be unique for all service instances provisioned in the application instance.

Draft of metadata file. Now, it is time to make a draft of the application metadata file. Describe application general information in the Specification terms. For details, refer to the 5.1 Common Application Properties section of the Specification. Add information written down on previous steps and replenish it with details.
Configuration script. Consider possibility to write separate configuration scripts for each service as in our example. Configuration script should perform all actions required for application configuration using environment variables defined on previous steps. Script for second-level service should configure user mailbox additionally. For the list of environment variables, refer to the Sample Environment Variables section further in this guide.
The application vendor states that any tenant/user could not be deleted, the only way to restrict access at all is to disable tenant/user. Considering this information, we added <status-control/> element to both scripts.

Add information about scripts to the respective provision sections of the metadata file. For example,
```
<service id="context" class="service">				
```
```
 <provision>
```
```
  <configuration-script name="configure.php">
```
```
   <script-language>php</script-language>
```
```
   <status-control/>
```
```
  </configuration-script>
```
```
 </provision>
```
```
 <service id="account" class="account">
```
```
  <provision>
```
```
   <configuration-script name="configure-mbox.php">
```
```
  <script-language>php</script-language>
```
```
    <status-control/>
```
```
   </configuration-script>
```
```
  </provision>
```
```
 </service>
```
```
</service>
```

Archiving application. Form application package requirements in the 4. Basic Package Format section of the Specification and archive it. The application is provisioned as external service, so application files themselves are not required. In our case, the structure is the following:

`APP-META.xml`	# Metadata container XML-file.
`sctipts/`
`configure` `configure-mbox.php` `elogin.php`	# The scripts will be invoked when upon service setup.
`images/`
`ox_calendar.jpg`	# Screenshots of the application