Glyue User Docs
  • What is Glyue?
  • Tutorials
    • Start Here
    • Building a Single-Step Integration
      • 1. Creating the Integration
      • 2. Calling the External System
      • 3. Running the Integration
      • 4. Crafting the Output
    • Building a Multi-System Integration
      • 1. Connecting to the Core
      • 2. Field Mapping
      • 3. Running the Integration
    • Building an Event-Driven Integration
      • 1. Setting up the Mock CRM
      • 2. Receiving Inbound Requests
      • 3. Triggering the Integration from the CRM
    • Building an Email Integration
      • 1. Create and Configure the Integration
      • 2. Input Validation
      • 3. Get Story IDs from Hacker News
      • 4. Get Story Content
      • 5. Sending the Email
      • 6. Wrapping Up
      • 7. Extra credit
        • extra_credit.json
    • Building a RESTful CRUD Web Service
      • 1. Integration Setup
      • 2. Vault Setup
      • 3. Create Web Service Endpoints
      • 4. Execute Web Service Endpoints with Vault Methods
      • 5. Vault Code Examples and Explanation
    • Building a Retrieval API against FIS CodeConnect
      • 1. Integration Setup
      • 2. Service Request Setup
      • 3. Field Mapping Setup
      • 4. Integration and Service Request Hook Setup
      • 5. Testing the Integration
      • 6. Common Errors
    • What is Pre-Mapping?
      • Before you start
      • Bookmarks
      • Source and Targets
      • Field Mapping Status
      • Field Mapping Comments
      • Summary
  • How-To Guides
    • How to Run an Integration from Glyue
    • How to Invite New Users
    • How to Create a Value Mapping Set
    • How to Build and Deploy a Custom Frontend
    • How to Migrate an Integration
    • How to Set Up Single Sign On (SSO)
      • Glyue Setup
      • JumpCloud Setup
      • Azure Setup
      • Okta Setup
      • Glyue SAML Config Reference
    • How to Install the Glyue App for Zoom Contact Center
    • How to use the Vault
  • Reference
    • Integration Builder Page
    • Integration Anatomy
    • Integration Components
      • Integration
      • Service Request
      • Field Mapping
      • Value Mapping Set
      • Value Mapping
      • Validation Rule
      • Mask
      • Integration Config
      • Integration Engine Versions
    • Integration Lifecycle
    • Special Functions
      • add_run_label
      • callint
      • debug
      • end
      • get_namespace
      • humanize
      • import_helper
      • keep
      • list_files
      • map_value
      • open_glyuefile
      • open_vault
      • Data Manipulation Utilities
      • calladapter
    • Special Variables
      • __adapter_config__
      • input
      • parentint
      • retvalue
      • run_history_id
      • Iterables
        • fitem/fidx
        • sritem/sridx
        • vritem/vridx/vrmsg
    • Adapters
      • Generic HTTP Adapter
      • Email SMTP Adapter
    • Web Service Endpoints
    • Vault Reference
  • Glyue Platform Reference
    • Banking Core Connectivity Guide
    • Authentication
    • Permissions
      • Service Accounts
      • Organizations
    • Frontends
    • Idempotency Layer
    • Integration Scheduler
    • Governance Reports
    • Arbitrary Integration Request Content Support
    • Admin Components
    • Logging
  • ETL
    • Glyue ETL Overview
    • Data Connectors
    • Workflows
    • Run History
    • Scheduler
Powered by GitBook
On this page

Was this helpful?

  1. Tutorials
  2. Building an Email Integration

2. Input Validation

You may remember that in the integration description we provided an example input that included a required email field and optional limitQuery and limitEmail fields. If the requestor doesn't provide an email address in their input, how would we know where to send the digest? Or, what if the requestor provides invalid limit values (which should be positive integers)?

In this case we want the integration to fail gracefully and respond to the requestor with a failure status and indicate which field(s) need to be fixed. This is where Validation Rules (VRs) come in to play.

Adding Validation Rules to the integration

  1. On the Build page, with Integration selected under Component at the top, right-click the row with hackernews_email_digest and select Go To > Validation Rule.

  2. Click the [➕ADD ROW] button 2 times to add 2 new rows. Enter the following values for each row:

    1. First row:

      • Type: INPUT

      • Field: input.payload.email

      • Rule: (copy and paste the below Python code)

        import re
        
        pattern = r"^\w[\w&'\+\-\.]*\b@[a-zA-Z\d][a-zA-Z\d\-]*\b\.[a-zA-Z\d]+[a-zA-Z\d\-]*[a-zA-Z\d]$"
        retvalue = _ and isinstance(_, str) and re.match(pattern, _)
    2. Second row:

      • Type: INPUT

      • Field: input.payload.limitQuery

      • Rule: (copy and paste the below Python code)

        not _ or (isinstance(_, int) and _ > 0)
    3. Select the second row and click the [DUPLICATE ROW] button at the bottom and make the following edits to the new row:

      • Field: input.payload.limitEmail

    4. Click the [💾 Save] button at the bottom.

If you are familiar with Python, you may have an idea of what is going on here. (_ represents the value of the field named in the Field column)

  • In the first validation rule, we ensure that the provided email exists, is a string, and a properly formatted email using a regex expression.

  • In the second and third, we ensure that, the limits are either not provided or are positive integers

Testing the Validation Rules

Now we’re going to validate that our new Validation Rules work correctly.

  1. Navigate to the Run History page. Select our most recent run, and click the curved arrow symbol on it. The Run Integration dialog window should appear.

    1. Copy and paste this into the PAYLOAD:

      {
        "email": "user@email.net",
        "limitQuery": 10
      }
    2. Click RUN INTEGRATION at the bottom. It should run successfully.

  2. On the Run History page, click the most recent integration and then the curved arrow again.

    1. This time, provide some invalid values in our payload:

      {
        "email": "invalid%email###@@123",
        "limitEmail": -1
      }
    2. Re-run the integration again. It should fail.

    3. Click the most recent run (once it appears- it may take a couple seconds). There should be two VALIDATION FAILURE records in the middle STEPS column. Clicking on them will provide information.

It's strongly encouraged to play around a little before continuing!

  • Try triggering the integration with various valid or invalid inputs.

  • Practice viewing them on the Run History page.

Previous1. Create and Configure the IntegrationNext3. Get Story IDs from Hacker News

Last updated 11 months ago

Was this helpful?