Tip: You can use filters for better results
-
Latest News
-
Getting Started
-
Work Place
-
-
-
- About Buttons
- Action Buttons
- Schedule Tickets
- Ticket Info and COMS Buttons
- Add Parts
- Assign Partners
- Remove Tickets from the Ticket Clipboard
- Inline Skill Editing
- Create Intervention Info
- Create Intervention Reports
- Cancel Tickets
- Cancel Appointments
- Clone Tickets
- Edit Ticket Details
- Edit Privat Notes
- Report Tickets
- Close Tickets
-
Admin Panel
-
FMA 2 App
-
Customer Portal
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.
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/myEndpointCalling 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.
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.
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.
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.
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.
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.
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.
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.
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.
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: Can I create an Incoming Mapping without authorization requirement?
- 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: Is there a maximum request body size limit on Incoming Mappings?
- 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 I send my request body as XML?
- 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 your system call our REST API using X or Y authorization method?
- Q: Can I set up timed/scheduled interface events?
A: No, unfortunately our Outgoing Mappings don’t support scheduled triggering currently.
- Q: Can I set up timed/scheduled interface events?
- 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.
0 out of 5 stars
| 5 Stars | 0% | |
| 4 Stars | 0% | |
| 3 Stars | 0% | |
| 2 Stars | 0% | |
| 1 Stars | 0% |
