General Events

Generally, an event source can be any APS type or APS resource. When an APS resource gets subscribed to another APS resource or to an APS type, the system will track the respective events of the respective sources.

List of Types

The following event types are available when subscribing to an APS type or resource:

Type	Event ID	Description
Linked	http://aps-standard.org/core/events/linked	Resource is linked with another resource (a link created)
Unlinked	http://aps-standard.org/core/events/unlinked	Resource is unlinked from another resource (a link removed).
Changed	http://aps-standard.org/core/events/changed	Resource configuration is updated.
Removed	http://aps-standard.org/core/events/removed	Resource was removed.
Available	http://aps-standard.org/core/events/available	New resource becomes available.

Example

The following example is taken from a sample package and demonstrates how to declare an event handler, subscribe to an event type, and process events. The OwnCloud application is available for users represented as LDAP user APS resources. Each LDAP user relates to a platform user. To keep the two resources synced, the users service must be notified of changes that happen with the platform user.

1. In the resource type (resource schema), we declare the onUserChange operation (see Operations for details) that is activated after receiving a POST request from the APS controller through the /onUsrChange path.

   "operations": {
       ...
       "onUserChange": {
           "verb": "POST",
           "path": "/onUsrChange",
           "parameters": {
               "event": {
                   "type": "http://aps-standard.org/types/core/resource/1.0#Notification",
                   "required": true,
                   "kind": "body"
               }
           }
       }
   }
   

   The received JSON object event must correspond to the Notification structure defined in the abstract APS type Resource.

2. Since the application needs to sync each LDAP user with the corresponding platform user, we subscribe the users service to changes in the platform user properties. Therefore, in the users.php script, we use the EventSubscription class defined in the APS PHP runtime. The service subscribes to the event each time a new LDAP user is provisioned, as defined in the provision() function. The subscription process is illustrated by the following excerpts from the provision() function:

   • Create a changed event subscription object based on the EventSubscription schema and declare the onUserChange function as the event handler.

     $sub = new \APS\EventSubscription(\APS\EventSubscription::Changed, "onUserChange");
     

   • Specify resources based on the service user type as the event sources.

     $sub->source->type="http://aps-standard.org/types/core/service-user/1.0";
     

   • Request the APS controller to create the event subscription ($sub) for the current resource ($this).

     $apsc = \APS\Request::getController();
     $subscriptionnotifications = $apsc->subscribe($this, $sub);
     

3. The onUserChange() function specifics are presented by the following excerpts:

   public function onUserChange($event) {
       $apsc = \APS\Request::getController();
       $serviceuser = $apsc->getResource($event->source->id);
       // ...
       // Example on tracking the *login* property:
       if($this->owncloudusername != $serviceuser->login) {
       // ... LDAP sync operations must be here ...
       }
   
       // Now sync the changes with the APS controller:
       $ownclouduser=$apsc->getResource($this->aps->id);
       $ownclouduser->owncloudusername=$serviceuser->login;
       $apsc->updateResource($ownclouduser);
       return;
   }
   

← Event Notification and Processing

Bind-to-Domain →