Introduction

Service configurations allow you to specify parameters and configuration for external services through a single common interface. EOS Administration Library provides support for a number of services out-of-the box, but you can easily implement your own service configurations with minimal effort and leverage this common configuration interface.

For each service configuration there usually exists a Codeunit for accessing this service. You can refer to the documentation of that specific service for details.

See below for a list of supported services.

Setup

You can access the service configurations from the page Service Configuration List (EAL). This page will list all currently configured services. From here you can manage existing services or create new ones.

A service configuration is made of two parts. On top, you will find a list of fields:

  • Code: Specifies a code you want to assign to this service configration
  • Type: Specifies the type of service you are configuring.
  • Description: Allows you to provide a user-friendly description for this service configuration.
  • Endpoint Uri: Allows you to to specify the URL this service points to. This may or may not be necessary, depending on the services implementation. Some services require this, other’s do not.
  • Request Timeout (sec): Allows you to specify a timeout for HTTP calls made to this service. If you don’t specify this, the default HTTP client timeout will be used. This may or may not be considered, depending on the services implementation. Some services consider this, other’s do not.
  • Logging: allows you to configure how (and if) requests and responses are logged for this service. This should only be used for debugging. You can read more on this below in the Debugging chapter.

Below, there is a subpage of service-specific parameters that are different, depending on the service that you are configuring. Refer to the documentation of each service for details.

Each parameter in this subpage can either be a normal parameter or a secret. This is decided by the service implementation. The only difference between the two is that a secret value can no longer be extracted, once it has been saved.

Debugging

Most services that are configured through a service configuration can be debugged. This is achieved by logging requests and their responses. This, however, depends on the services implementation.

To activate this debug log you must specify a value other than None in the field Logging. This allows you to log every request (and their response) or only failed ones.

Once you active the log, all further requests made using this service configuration will be logged. You can access the log from the Service Configuration card, from the action Resquest Log. This page allows you to see all the requests since activating the log and also allows you to download the request and response data (as JSON).

Supported Services

The following services are supported out-of-the box by EOS Administration Library.

Azure FileStorage

This service provides access to the Azure FileShare storage for reading and writing files. The following configuration parameters are available:

  • AccessKey: The access key credential to use.
  • AccountName: The name of the Azure storage account.
  • FileShareName: The name of the file share inside the Azure storage account.

EOS FunctionAPI

Provides access to an instance of an EOS Function API installation. The following configuration parameters are available:

  • X-EOS-Api-Key: The API key to use when calling making requests.

ApplicationInsights Query Allows executing KustoQL queries against an Application Insights account. The following configuration parameters are available:

  • ApiKey: The API key credentials you have created on your application insights account to use.
  • ApplicationId: The application ID of the account to use. You can find this in the configuration of your application insights account.

Azure BlobStorage

This service provides access to the Azure BLOB storage for reading and writing files. This configuration will use the storage module of the base application. The following configuration parameters are available:

  • SharedKey: The access key credential to use.
  • StorageAccount: The name of the Azure storage account.
  • ContainerName: The name of BLOB container inside the Azure storage account.

In-Memory Storage

This is a mock storage for use with the IFileSystem interface. This is useful for testing and development whenever you don’t have an actual file-system available. The files are stored in-memory for your session only and are not visible to anyone else. Also, any files are lost when you close your session. The following configuration parameters are available:

  • StorageName: You can have multiple in-memory storages at the same time. Each one is identified by this name. You can choose any name you want.

Application Insights

This replaces the obsolete ApplicationInsights Query. This new implementation allows executing KustoQL queries, just like it’s predecessor did. In addition, it also allows to post logs to an application insights ingestion endpoint. For this, you need to specify the application insights connection string, where you want to post your logs to, in the Endpoint Uri field.

The following configuration parameters are available:

  • ApiKey: this is only required when executing queries. The API key credentials you have created on your application insights account to use.
  • ApplicationId: this is only required when executing queries. The application ID of the account to use. You can find this in the configuration of your application insights account.

EOS Labs -