edoc content services Guide
edoc content services Guide
Breadcrumbs

Things to know about edoc content services

Learn about the basic technical concepts and special features of the service in this article.

A basic understanding of the following technical concepts is helpful for working with edoc content services:

  • Local hosting and hosting in the cloud: edoc content services is designed and implemented in such a way that the adapter can be used both on-premises and in the cloud (e.g. Microsoft Azure). For edoc content services to function correctly, you only need to be able to establish an HTTP connection to the destination system.

  • No data storage: edoc content services does not persist any data. For technical purposes, only the data types of document properties are stored in an in-memory database (Redis). This data is only stored temporarily in the working memory and is lost after a restart. The data is recreated as required.

  • Stateless processing: edoc content services works stateless. You must also provide all the necessary data for each request, such as the address of the destination system or login information (credentials).

  • Error handling of destination systems: edoc content services communicates with destination systems where errors can also occur. The errors of the destination systems are simply displayed in their original form in edoc content services and are neither processed, evaluated nor translated. If the errors are not clear or understandable, take a look at the log of the destination system. The information about the error in the log is often more extensive than the error message displayed.

  • Log for edoc content services: edoc content services writes a log to record the behavior of the service. By default, you will find the log in the console of the Docker container in which the service is running.

  • Supported destination systems (modules): Modules, also known as connectors, refer to the supported destination systems. In order for edoc content services to recognize the form in which the requests must be sent to the corresponding destination system, you must specify the ID of the desired destination system each time it is called. You can find out which destination systems the respective edoc content service instance supports under the /system endpoint.

  • Connection string: You may be familiar with the term connection string from various database systems. The connection string is used to transport connection data. This connection data is specified in Key/Value constructs (name=value). These constructs are then listed one after the other in a string and separated from each other by semicolons. In edoc content services, each module has its own connection string. The connection data for the respective destination system can be found under the /System endpoint. Example: targetHost=https://test.sharepoint.com;User=sharepoint_user;Password=sharepointuser_password;ListId=ac4af181-dd54-4735-bad3-42517e8653f1;

Things to know

The connection string is transmitted to edoc content services as the header parameter of an HTTP call.

According to the RCF 7230 specification, only characters from the US-ASCII character set may be used in header parameters. The restriction to the US-ASCII character set can lead to problems with password values if passwords contain characters from other character sets, e.g. umlauts.

Recommendation: Only use characters from the US-ASCII character set for a connection string and especially for passwords.

The following special features apply to the processing of data:

  • Unix Timestamp as standard date format: edoc content services can be executed in a microservices infrastructure together with other edoc apps and edoc services. For this reason, all apps and services must use the same date format. The Unix Timestamp standard (Unix time) therefore applies to all properties (attributes) of type Date or DateTime. The format is also used for the output of attributes.

  • JSON format for the transported data: The user data (payload) is the data of a data packet during communication between the apps and services. The payload data can be found in the body of an HTTP request. edoc content services uses the JSON format for this data.

  • Limited number of files per document: There are some destination systems that can contain more than one file per document. edoc content services is designed so that the adapter can only process one file per document. When a document is created, you can only upload a single file. Even if a document contains several files, edoc content services only ever delivers a single file. This file is always the first file that the destination system delivers.

The edoc content services REST API offers various options for development teams:

  • Use API functions easily: You can use the REST API with various programs, e.g. Postman.

  • Description of the endpoints in Swagger: edoc content services offers a Swagger UI that contains all endpoints with a description. You can open the Swagger UI in the browser and simply try out all endpoints. You can also download the swagger.json file, which you can use to automatically create a web client for edoc content services for some programming languages.

  • API version: The API is available in two versions: 1.0 and 1.1. The only difference between the versions is the endpoint for creating files. In version 1.1, multivalued fields can be filled in files by sending the header parameter X-Version: 1.1 with the request. If you do not send the parameter, version 1.0 is used by default. For more information about transferring multiple fields, see: Create a file

You can find the API by default at the URL https://<hostname>/api/content-service.

Find out more about the special features of the individual modules under: Features of the individual modules in edoc content services