The Eventing Lifecycle

    +
    This page shows how to add a new Eventing Function and briefly explores the Eventing Lifecycle.
    lifecycle overview notitle

    This is a quick introduction to Eventing via creating a simple Eventing Handler and subsequently exercising the Eventing Handler’s functionality and operations across its typical lifecycle. For a deeper insight refer to the more detailed Eventing Examples.

    Prerequisites:

    In order to show the basic life cycle of an Eventing Function, we need a Listen To Location (a source keyspace) and a separate Eventing Storage keyspace. You must have an Eventing storage keyspace, which should be typically 100% resident, and the collection is to be used solely by the Eventing Service.

    For the Listen To Location or source keyspace we will use the beer-sample._default._default sample document set.

    If you don’t already have the sample document set beer-sample (it should have a scope of _default and a collection of _default) listed in the Couchbase Web Console > Buckets page you can load this sample data set as follows:

    • Access the Couchbase Web Console > Settings page

    • Select the Sample Buckets in the upper right banner.

    • Check beer-sample checkbox.

    • Click Load Sample Data.

    For the Eventing Storage keyspace we need to create one if missing as follows:

    • Access the Couchbase Web Console > Buckets page

    • Select the Add Bucket in the upper right banner.

    • In the dialog set the "Name" of the bucket to rr100 and set "Memory Quota" to 100 MiB.

    • Click Add Bucket.

    At this point we could use the Eventing Storage keyspace of rr100._default._default, for all Eventing Functions but we might want to split this up by a logical grouping (or alternatively by tenants):

    • Select Scopes & Collections at the right of the new bucket information line.

    • Select the Add Scope in the upper right banner.

    • In the dialog set the "Name" of the Scope to eventing.

    • Click Save.

    • Select Add Collection at the right of the new scope information line.

    • Click Save.

    If we return to the Couchbase Web Console > Buckets page you should see two (2) buckets.

    addfunc 00 prerq bkts

    If we now select Scopes & Collections at the right of the rr100 bucket information line, then expand eventing you should see the metadata collection.

    addfunc 00 prerq bkts s c

    Create an Eventing Function:

    1. From the Couchbase Web Console > Eventing page, click ADD FUNCTION.

      An empty ADD FUNCTION dialog is shown:

      addfunc 01 empty settings

      The ADD FUNCTION dialog enables the developer to provide the following information:

      Table 1. Add a Function Dialog
      Elements Description

      Listen To Location (the source keyspace)

      The name of a collection currently defined on the cluster.

      For complete details on how to set up your keyspaces refer to creating buckets and creating scopes and collections.

      Eventing Storage (the Eventing metadata keyspace)

      The name of a collection currently defined on the cluster. The Eventing Storage (or Metadata) collection, stores artifacts (or configuration documents) for your Function. A common Eventing Storage collection can be shared across all Eventing Functions for the same tenant.

      For complete details on how to set up your keyspaces refer to creating buckets and creating scopes and collections.

      Function Name

      A name, for the Function you are creating. All Eventing Functions must have a unique name in a Couchbase cluster.

      Deployment Feed Boundary

      Using the Feed Boundary drop down, you can either set a handler to deploy for all data mutations available in the cluster (Everything) or choose to deploy the handler to process only future data mutations, post deployment (From now). The Feed Boundary is a persistent setting in the Function’s definition and can only be set or altered when a Function is created, undeployed or paused.

      Description

      The Description is an optional text that can be added to the Function, typically to describe the purpose of the particular business logic. This is optional.

      Settings

      The available settings (by default hidden within a collapsible panel) for complete details refer to Terminologies - Function Settings:

      • System Log Level: Determines the granularity at which messages are logged to the common system log messages across all Eventing Functions. The available choices are: Info (the default), Error, Debug, Warning, and Trace. Leave this alone unless asked by support to change it.

      • Application log location The directory path to the log file for the application or the Function specific log messages named [function_name].log. The Function designer uses log() statements to write to this file in addition it will also record some Function specific system level errors. In the UI when "Log" is selected these files are combined across all Eventing nodes and displayed. This path is set at node initialization.

      • N1QL Consistency: The default consistency level of N1QL statements in the handler. This controls the consistency level for N1QL statements, but can be set on a per statement basis. The valid values are None (the default) and Request.

      • Workers: Workers the number of worker processes to be started for the handler. The minimum value is 1 (the default) and the recommended maximum is 64.

      • Language compatibility: The language version of the handler for backward compatibility. If the semantics of a language construct change in any given release the “Language compatibility” setting will ensure an older handler will continue to see the runtime behavior that existed at the time it was authored, until such behavior is deprecated and removed. Note 6.0.0, 6.5.0, and 6.6.2 (the default) are the only currently defined versions.

      • Script Timeout: Script Timeout provides a timeout option to terminate a non-responsive Function. The entry points into the handler, e.g. OnUpdate and OnDelete, processing for each mutation must complete from start to finish prior to this specified timeout duration. The default is 60 seconds.

      • Timer Context Max Size: Timer Context Max Size limits the size of the context for any Timer created by the Function. Eventing Timers can store and access a context which can be any JSON document, the context is used to store state when the timer is created and retrieve state when the timer fires. By default the size is 1024 bytes, but this can be adjusted on a per Function basis.

      Bindings

      A binding is a construct that allows separating environment specific variables (example: bucket names, external endpoint URLs, constants) from the handler source code. Currently Eventing Functions support the following binding types:

      • Bucket Bindings: to access the Data Service or KV.

      • URL Bindings: to communicate externally via cURL.

      • Constant Bindings: to pass global settings/constants into the function.

      An Eventing Function can have no bindings, just one binding, or several bindings. For more information on Bindings, refer to Terminologies - Bindings.

    2. In the ADD FUNCTION dialog, configure the following information:

      • For the Listen To Location drop-downs, select beer-sample for bucket, _default for scope, and _default for collection.

      • For the Eventing Storage drop-downs, select rr100 for bucket, eventing for scope, and metadata for collection.

      • Enter my_evt_function as the name of the Function you are creating in the Function Name text-box.

      • [Optional Step] Enter text A simple Eventing Function only prints IDs, in the Description text-box.

      • For the Settings option, use the default values, feel free to expand this section and inspect.

      • For the Bindings option, don’t add any bindings (we will merely be logging messages).

        addfunc 02 settings

        Note, we left the Settings alone, however if you expanded the collapsible Settings control you can see the defaults that the Function will use:

        addfunc 02 adv settings
    3. After providing all the required information in the ADD FUNCTION dialog, click Next: Add Code. The my_evt_function dialog appears.

      • The my_evt_function dialog initially contains a placeholder code block. You will accept the default for your my_evt_function code.

        addfunc 03 editor with default
      • You will need to click Save and Return if you modified the JavaScript source.

      • To return to the Eventing screen, click the '< back to Eventing' link (above the editor) or just click the Eventing tab.

    Exercise the Eventing Lifecycle:

    1. Click on the Function name.

      addfunc 04 newundeployed

      Additional controls are now displayed. The controls are:

      • Delete: Deletes the Eventing Function from the system.

      • Export: Exports the Eventing Function as a JSON document.

      • Deploy: Deploys the Eventing Function, making it active across the cluster.

      • Pause: Pauses the Eventing Function, making it paused across the cluster (only allowed if the Function is Deployed). If a Function is paused this button will be renamed Resume.

      • Edit JavaScript: Allows edits to be made on the Eventing Function, in an edit dialog (only allowed when Paused or Undeployed). When deployed this button is renamed View JavaScript.

    2. From the Eventing screen, click Deploy.

      addfunc 04a deploy
      • In the Confirm Deploy Function dialog, note that Everything is the preferred Feed boundary.

        The Feed Boundary determines whether documents previously in existence need to be included in the Function’s activities: the options are Everything and From now. The Everything option invokes a Function on all mutations available in the cluster from the Listen To Location keyspace. The From now option invokes a Function during future instances of data mutation, post Function deployment or new changes to the Listen To Location keyspace. The preferred Deployment Feed Boundary for the function can be changed under the function level settings when the Function is undeployed or paused.

      • Click Deploy Function.

    3. While the Eventing function is bootstrapping it will display a status of "deploying…​" in the UI. Once the bootstrapping is complete the defined Function’s JavaScript code is executed on all existing documents and then on subsequent mutations. This function will only perform logging operations.

      input output overview 6.5

      The deployment process typically takes about 15 seconds. Once the Eventing Function is fully deployed its status will change from deploying…​ to a status of deployed. At this point the Eventing service will quickly process all of the 7,303 items in the collection because the Feed boundary was set to Everything in the Function’s settings. Finally the Function will await any new mutations and immediately process them in real-time as they occur.

      addfunc 05 deployed done

      Since the example only has a single log(…​.) statement in the OnUpdate handler it will merely list items in the collection 'beer-sample', i.e. 7,303 documents.

      You should see the success count at 7,303 in the Function’s basic statistics.

    4. Verify that the deployment and processing actually worked by clicking the Log link that appeared after you the Eventing Function reached a status of deployed. The Log link appears in the right hand side of the Function’s controls.

      • A dialog showing the Function Log - my_evt_function will appear with the most recent logging information (in reverse order with the most recent lines first).

        addfunc 06 logs emitted
      • Click Close.

    5. To pause a Function (you can then edit and update the function without missing a mutation)

      addfunc 07 pause
      • Click Pause.

      • In the Confirm Pause Function dialog

        • Click Pause Function.

      • The Eventing function will now create a checkpoint of its progress and pause.

      • Wait for the "paused" state.

    6. To resume a function that has been paused

      addfunc 07 resume
      • Click Resume.

      • In the Confirm Resume Function dialog

        • Click Resume Function.

      • The Eventing function will now resume from the previously created checkpoint (no mutations will be missed).

    7. To undeploy the Eventing Function my_evt_function

      addfunc 07 undeploy
      • Click Undeploy.

      • In the Confirm Undeploy Function dialog

        • Click Undeploy Function.

      • The Eventing function will now undeploy.

      • Wait for the "undeployed" state.

    8. To delete the Eventing Function my_evt_function

      addfunc 08 delete
      • Click Delete.

      • In the Confirm Delete Function dialog

        • Click Delete Function.

    The Eventing Function lifecycle operations (deploying, undeploying, pausing, resuming, and deleting operations) and the Eventing rebalance operation are mutually exclusive. The Eventing rebalance operation fails when an Eventing Function lifecycle operation is currently in progress. Likewise, when the Eventing rebalance operation is in progress, you cannot perform an Eventing Function lifecycle operation.