Fieldcode Manual

Tip: You can use filters for better results

Fieldcode Direct Connection Interface Explained

This page provides a summary of what the Fieldcode Direct Connection Interface is, and how it works.

Introduction

We provide our customers with dynamic REST API endpoints with scripting support for handling webhooks, and event based scripts which allow callbacks to external REST API-s. Our goal is to ensure maximum customization of a bi-directional communication with least amount of work required on the customer system.

In Fieldcode the interface scripts are generally referred to as mappings, indicating their purpose for transforming an incoming data model to our internal representation and vica versa. The dynamic REST API endpoints are called Incoming Mappings, and the Workflow event scripts are called Outgoing Mapping. Incoming Mappings and Outgoing Mappings are grouped under interface Systems to keep different interface connections isolated.

Incoming Mappings

Incoming Mappings combine a dynamic REST API endpoint definition and a script function which allows you to dynamically handle any incoming external request in our system.

Asynchronous processing

Our interface system is completely asynchronous and queues every request to keep processes in order, so using the dynamic endpoints for fetching data is not possible.

Endpoint definition

Each Incoming Mapping creates a custom endpoint available under your tenant’s domain. For example, creating an Incoming Mapping under the System “mySystem” with path “myEndpoint” and HTTP method “POST” will create and expose the endpoint:
https://myTenant.fieldcode.com/dc/mySystem/myEndpoint
Calling this endpoint with the configured POST HTTP method and a suitable authorization method will invoke the script function defined for this endpoint.

Authorization methods

You can secure your endpoint with using one of our available authorization methods.

API Key

An API Key is the simplest form of authorization against your endpoint, requiring only a single key to access it. To use an API Key simply add it to the end of the URL in the “apiKey” query parameter:
https://myTenant.fieldcode.com/dc/mySystem/myEndpoint?apiKey=myApiKey

API Keys can be revoked any time or set up with an expiration date. While they are not the most secure option, they are useful when the connecting system doesn’t support any other authorization method.

Basic Auth

Basic Auth is using the combination of a email and password, making it more secure than API key. To use this method you must create an Interface User – regular users are not authorized to call Incoming Mapping endpoints.

OAuth2

Similarly to Basic Auth, OAuth2 also uses an Interface User, but with the extra step of first retrieving a Bearer token from our OAuth2 server, then using this token to make a call to the endpoint, adding an extra layer of security.

Permissions

To further increase security on your interface you can also create custom permissions to restrict Interface User/API Key access to specific endpoints only.

For your first connection we recommend using the “default” permission.

Permission validation

An API Key/Interface User is only authorized to call an endpoint if at least 1 of their permission matches!

Payload schema

Our system expects a single JSON object request body for calling any dynamic REST API endpoints. Setting up your JSON object schema is completely optional, but allows you to pre-handle the data model before the actual mapping.

Uploading an example payload

If you have a dedicated payload model that you will send to your Incoming Mapping, you can upload an example JSON of it and our system will validate every incoming request to see if it matches your required model.

Validating and fine tuning your schema

Using the Schema Fine Tuner you can set up required fields and specific types. For these types our system will auto-convert your field values, so you won’t have to bother with parsing in your Mapping script.

JSON objects only!

Requests with JSON arrays or primitive JSON values as body are not accepted by our system and will end up as Rejected processes!

Group definition

While incoming requests are grouped by System, the resulting processes are grouped into dedicated queues. Processes within the same queue are processed one by one, keeping strict order to ensure consistency.

Default grouping

Recommended for your first interface connection, this setting will group every process on your endpoint under the same queue.

Blocked queues

The default group definition will always block follow-up requests on a validation or mapping error!

Ticket grouping

For Ticket related requests you can use the “ticket” grouping option. Ticket grouping requires a single-line Fieldcode Embedded Python expression to calculate the suffix of your Queue name.

CNE based queues

Providing the same expression used to calculate your ticket CNE will result in both your Incoming and Outgoing Mapping processes of the same ticket ending up in one Queue.

Custom grouping

Only recommended for experienced users, the custom grouping allows you to write a single-line Fieldcode Embedded Python expression to calculate your Queue name, which makes it possible to group processes across different systems.

By using one of the non-default group definitions, you are also able to set your Queue to continue after a failed request by turning on the “Continue on failure” option.

Managing your queues

You can lookup your queues in the Interface Monitoring panel using the queue name provided under the "Definition preview".

Here you can also unblock any blocked queues by either acknowledging or fixing the responsible error and retrying the Rejected process.

Fallback grouping

When using a payload field for ticket or custom grouping, the grouping may fallback to the default grouping definition if your payload fails the validation step!

Incoming Mapping script

In the attached script function of the Incoming Mapping you gain access to the HTTP request payload under the “data” variable and may set up any data transformation, and system API call including but not limited to: creating and updating tickets and dynamic objects, adding absences to engineers, uploading attachments.

Our system currently only supports a type-safe subset of the Python script language. For further information please refer to our Fieldcode Embedded Python API documentation.

Responses

Our system is fully asynchronous, meaning any request will be processed after the response is returned. The response is not customizable in the Mapping script and can not return additional data.

Calling an Incoming Mapping REST API endpoint will result in one of the three expected responses.

    1. Process started response

      Status code: 200

      {
        "message": "Process started asynchronously. Use the returned URL in the Location header to track the process state.",
        "data": null,
        "error": false,
        "correlationId": "xyz",
        "code": "M-0-030-000"
      }

      This response indicates a successful request, where both the authorization and the request body validation succeeded, creating a process in our system. You may keep track the asynchronous processing using the Location header of the response, or the Interface Monitoring panel.

    1. Preprocessing failed response

      Status code: 200

      {
        "message": "Process was created but preprocessing failed:\nInvalid request body! Schema violations: \n[...]",
        "data": null,
        "error": true,
        "correlationId": "xyz",
        "code": "M-0-030-000"
      }

      This response indicates an error during request body validation. This will always result in a Rejected process created in our system that may block any follow-up requests depending on the Group definition setting.

  1. Unauthorized response

    Status code: 401

    {
      "message": "Unauthorized",
      "data": null,
      "error": true,
      "correlationId": "xyz",
      "code": "M-7-030-132"
    }

    This response indicates an error with your authorization process. If you get this error, make sure to double check whether your API Key query parameter or Authorization header is properly included and your Bearer token – in case of OAuth2 – is not expired. Additionally, make sure that at least one Permission of your API Key/Interface User matches the defined permissions of your endpoint.

Outgoing Mappings

In Fieldcode the Outgoing Mappings act as an alternative to webhooks. Compared to webhooks, Outgoing Mappings give you the power to completely alter and enrich our internal models via scripting, and allows you to trigger these scripts straight from your custom project workflow, exactly where you need them.

Trigger definition

An Outgoing Mapping itself defines a callback that will be available in the Workflow editor under the “Interface webhook” action. For example, to call an external system whenever your ticket reaches the Appointment status, you first need to set up an Outgoing Mapping for object type “ticket” and your desired Interface System, then add your new Outgoing Mapping to your Workflow’s “appointment” node, using the “Interface webhook” action.

Important: When a System has the “Unrestricted use” option disabled, Outgoing Mappings of that System will only work for tickets which are either outsourced to the given system (requires the “Outsourcing” System option enabled), or that were created by an Incoming Mapping of the same System.

Important: Customizing the group definition for Outgoing Mapping is currently not available. All triggered processes will be grouped under object specific queues, with the following naming pattern: {mySystem}/{myObject}:{myObjectId}
.

Outgoing Mapping script

Similarly to the Incoming Mapping, the attached script function of the Outgoing Mapping gives you access to the model of the selected object type under the “data” variable. Here you can set up any data transformation, enrichment and external API calls.

Our system currently only supports a type-safe subset of the Python script language. For further information please refer to our Fieldcode Embedded Python API documentation.

F.A.Q.

    • Q: Can I create an Incoming Mapping without authorization requirement?
      A: No, for security reasons authorization is always required. However, API Keys are included in the query parameters of the URL, making our endpoints also available to systems without proper authentication support.
    • Q: Is there a maximum request body size limit on Incoming Mappings?
      A: Our system allows up to 50 MB to be sent in a single request.
    • Q: Can I send my request body as XML?
      A: Our REST API only works with JSON objects at the moment, but we may introduce support on request.
    • Q: Can your system call our REST API using X or Y authorization method?
      A: In the Python scripts we have built-in support for Basic Auth and OAuth2 as well as API Key and Bearer token.
    • Q: Can I set up timed/scheduled interface events?
      A: No, unfortunately our Outgoing Mappings don’t support scheduled triggering currently.
  • Q: Can I parse raw embedded JSON string into JSON object during mapping?
    A: JSON parsing within mappings are not directly available but will happen automatically on HTTP requests.
Was this topic helpful?
0 out of 5 stars
5 Stars 0%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
5
How can we further improve this topic?
Please provide the reason for your vote. This will help us improve this topic.
Navigation