# Applications

# Overview

A CloudWright application is where a tool's logic lives. The entrypoint to every application is a file named script.py. This file may import functions from other files in the same application. Within script.py (or in imported helper files), a CloudWright application will do one or more of the following:

  • Declare inputs
  • Include and use modules
  • Define application logic (the part you care about!)
  • Write output to a response

The CloudWright IDE is the environment where users build, configure, test, and publish applications.

Template App

This article outlines the building-blocks of a CloudWright application; the [Web IDE] article highlights the development and testing assistance features of the in-browser editor.

# Configuration

When creating a CloudWright application, you'll need to set several initial properties. Some of these can be edited later, but others cannot be changed.

Template App

The visibility of your application has important security and deployment implications. An application can either be configured with 'Personal' visibility, or shared with a team which you belong to.

  • Personal applications can only ever be viewed, edited, or run by you. A personal application can include modules from any team you belong to, or personal modules.

  • Shared applications can be edited or run by other members of the team with which the application is shared. A shared application can only include modules from the team it belongs to.

The visibility of an application cannot be changed after creation.

The Display Name of an application is the UI-visible name of an application. This can be changed at any time, and has no restrictions.

The ID of an application, however, is a permanent identifier which is embedded in programmatic references to your application — for example, when constructing HTTP URL addresses or SQS queue names. Because this ID is used as a public identifier for your application, it cannot be changed after the application is created.

A Description is a short summary of what an application does. This does not have to be exhaustive — there is a separate README section where you can provide long-form, markdown-formatted documentation for an application. An application's description can be edited at any time.

When an application is run, it executes in a specific Deployment Zone. A Deployment Zone represents a network environment within a cloud provider. By default, applications execute in a Deployment Zone managed by CloudWright. If your application needs access to internal resources (like a database with an internal IP address), you can set up a custom Deployment Zone hosted on your cloud.

For most applications, it makes sense to report all Application History to CloudWright. By reporting both successes and failures, you'll be able to view all application executions in the History UI.

However, for certain high-throughput applications — for example, an application which services an HTTP API endpoint — the volume of records produced may slow down the CloudWright server or clutter the History UI. If you expect an application to be run more frequently than once a minute, you should consider reporting only errors.

Logging granularity can be changed at any time, but changes will not take effect until the application is re-published.

# Inputs

CloudWright applications declare explicit input arguments by pulling them out of the globally accessible CloudWright.inputs object:

my_input = CloudWright.inputs.get("input1")

Input arguments are auto-detected by parsing your application's source code; if your inputs don't require documentation, you don't have to do anything else. However, you can attach a custom 'Display Name' and 'Description' to each of your declared inputs in your application's advanced configuration menu (accessed by clicking the wrench in the upper-right corner of the editor window):

Advanced Config

In the 'Inputs' tab, you can add a display name and description to each declared input.

Input Descriptions

These custom display names and descriptions will be published alongside your application. For example, when running the application via the Run Console, the input display names and descriptions will be shown:

Template App

# Using Modules

To add a Module to an Application, navigate to the 'Modules' tab in the right sidebar, and click 'Edit'. This takes you to the module selector view:

Edit Modules

From the left column, select the modules you want to include in this application, and save your changes.

Changes to an application's modules will start a new image build (as indicated by the spinning icon in the Module viewer). Autocomplete in the IDE editor will pick up changes immediately, but it will take a minute or two before you are able to dry-run an application using the new module list.

# Importing Modules in Applications

To import a module in an application, you will import it using the module's import key. If multiple imports share an import key, you will also need to specify the module's ID

  • A Module's import key refers to the template it was created from. For example, all Salesforce modules you create will share the salesforce import key, even when they connect to different Salesforce accounts.
  • A Module's ID refers to a specific Module instance you create. No two modules can ever share an ID.

To reference a Module in your Application's source code, use CloudWright.get_module with the import key:

my_module = CloudWright.get_module("salesforce")

If you have attached multiple Modules with the same import key to your Application, you must select a specific instance by also supplying the ID of the Module:

module_1 = CloudWright.get_module("salesforce", instance="my_specific_salesforce")
module_2 = CloudWright.get_module("salesforce", instance="my_other_salesforce")

A module's import key (and ID when needed) can be found by expanding the module in the sidebar, and will also be supplied by autocomplete.

# More on Modules

For more details about modules, including what kinds of modules can be created and what you can use them for, see the modules section. Alternately, for a step-by-step guide to creating and using a module, see the creating a module guide.

# Responses

The easiest way for an application to return a value is by writing to the CloudWright.response object. For example, an application can return a simple JSON response by calling set_value on the response object:

CloudWright.response.set_value({"key1": "value1"})

For convenience in building applications with rich output displays, the CloudWright UI directly renders HTML in all application run contexts if the response_type is set to 'text/html':

Template App

# Publishing

Changes to an application's code will not affect triggered or manual runs until the application is published. Likewise, changes to trigger configurations will not take effect until the next time an application is published.

To publish an application, click the 'Publish' button in the 'Publish' tab in the lower-right. After publishing an application, it may take several minutes for all changes to apply; the 'Publish' status indicator will tell you when this is complete. For complete details, you can click the indicator to view real-time logs.