Experiences

Building a product on top of WEGnology would normally involve writing an API service, implementing user authentication, building and serving a front-end interface, and hosting all of the above somewhere – which is a lot of work! Experiences bring all of this functionality directly inside your WEGnology application.

WEGnology Platform

Experiences are a means by which you can build a fully functional web interface, allowing users to interact with your connected Devices. Set a subdomain at which your Experience Views can live; return user-specific Dashboards with content that is specifically relevant to them; configure Endpoints to respond to requests using the power of WEGnology’s Workflow Engine; register Experience Users against your application; or build a full multi-tenant application by assigning your users to Experience Groups.

How Experiences Work

An Experience’s Endpoints, Workflows, and Pages all work together to deliver completely custom user interfaces and APIs.

1. Endpoint Request

Endpoints define the custom routes that users request using a web browser or an API client.

GET /pumps/{pumpId} HTTP/1.1

2. Trigger Workflow

Endpoints trigger Experience Workflows, which query all data from your devices or data sources required to fulfil the request.

{
  "pump": { ... },
  "location": "39.108, -84.50",
  "rpm": 1100
}

3. Render Page

Workflows can return raw data or pass it to an Experience Page to be rendered as HTML, or a Dashboard Page to render a WEGnology Dashboard.

<p>
  Name:
  {{pageData.pump.name}}
</p>
<p>
  GPS:
  {{pageData.location}}
</p>

Getting Started

New application Experiences must first go through a short bootstrapping process before you can begin using the features.

Choose a Slug

Bootstrap Slug

The first step in working with Experiences is to choose a custom endpoint slug, which is a subdomain at which your endpoint requests will live. It is here that endpoint requests can be securely received and responded to. After initial setup, you may also configure one or more full domains for handling endpoint requests as well as additional endpoint slugs.

By default, your application experience includes a slug that matches your application ID; this slug cannot be deleted. If you choose to enter a custom slug during the bootstrapping process, the slug must meet these requirements:

Must be at least 4 characters
May only contain lowercase letters, numbers, hyphens (-) and underscores (_)
Must be unique across the entire WEGnology Platform
Cannot be a commonly used Internet subdomain, such as “webmail” or “cpanel”
Cannot be profane (slugs violating this rule are subject to change without notice)

HTTP requests for your endpoints should then go to https://[my-custom-slug].wnology.io/[my-endpoint].

Bootstrap Your Experience

After choosing a slug, you’ll have the option of setting up some example resources to get you started. This step can be skipped on a per-application basis, though we recommend completing it as a great starting point for building out a full experience.

Bootstrap Choose

If you choose to create the helper resources, WEGnology will automatically add the following to your application:

Two /login endpoints (one for GET and one for POST requests), a backing workflow (which handles the actual authentication and routing), and the page to render when the endpoints are requested.
A /logout endpoint and a backing workflow for signing users out.
A / (root) endpoint configured to render another page for signed-in users and to redirect to the login page for unauthenticated users.
The layout and components necessary to render the pages listed above.
A test Experience User for testing authentication and protected endpoints.
An Experience Group with the test user as a member.

The sample resources utilize a placeholder brand and a layout wrapped in Twitter Bootstrap, a popular front-end framework whose stylesheets and script files are available on a content delivery network. You are free to continuing using this framework to build out your experience, or to swap it with another of your choosing (or no framework at all).

All of these resources can be updated or deleted at any time. If you delete all your experience resources, you will have the option of running the bootstrap process again.

Test Your Experience

Finally, if you chose to create the sample resources, you’ll receive instructions for testing your new endpoints and views. Click the link provided on the summary screen, which should redirect you to your new login page. Sign in with the provided credentials and you will then see the placeholder home page.

Bootstrap Review

The email address and password for the test user is included in the summary modal. Before opening up your application experience to real users, you must delete this test user to mitigate against unauthorized access to your application experience.

If you chose to skip the resource creation step, the modal will simply dismiss when you set your slug.

Deleting Experience Resources

If for any reason you need to delete parts or all of your Experience, you can do so under the “Settings” -> “Application Info” tab in your application’s sub-navigation and then selecting “Delete Resources” in the top navigation tabs. Select all the resources you wish to delete and then submit the form.

Bulk Delete Experience Resources