Fluent Commerce Logo
Docs
Sign In

commercetools Connector Extend Configuration

Feature

Changed on:

31 Jan 2024

Overview

The commercetools-connector expects a minimum of 4 configuration files:

  • application-connector.yml - Project and Connector specific configuration.
  • application.yml - Core Connect commercetools-connector configuration. These are mostly default configurations and core settings.
  • bootstrap.yml - Server/Container configuration. This file includes settings for all different environments and -follows the spring profile standards.
  • logback-spring.xml - Log configuration also supports different configurations based on spring profiles.

It is possible to have dedicated configuration files for each environment. This is often used to override a common setting for a particular environment. To create such a file, follow SpringBoot's format having the additional desired spring profile name at the end of the application.yml file, for example: application-dev.yml.

Detailed Technical Description

Credential / Secrets Configuration

In order for the commercetools-connector to connect to external systems, it requires access to their credentials and these must be stored in a secure location. The commercetools-connector provides a way for new credential storage services to be added and this is covered in the customisation guide. To configure your credentials, follow the Credential / Secret Setup Guide.

Common Configuration

commercetools Connector Listener Configuration

Before configuring the actual listeners, let's first look at the commercetools-connector settings as these will impact how listeners are initiated within the commercetools-connector.

Property

Required

Description

message-listener-mode

yes

Sets the commercetools-connector message listener type. This controls what kind of listener is used for the commercetools-connector message queue only, and external listeners are not impacted by this setting.

batch-listener-mode

yes

Sets the commercetools-connector batch listener type. This controls what kind of listener is used for the commercetools-connector batch queue.

available-listeners

yes

Lists of all available listeners for the commercetools-connector. If a listener is not listed here, the commercetools-connector will not consider it.

1fluent-connect:
2  message-listener-mode: sqs
3  batch-listener-mode: sqs
4  available-listeners:
5    - "sqs"
6    - "kafka"

Language: java

Name: Example

Description:

[Warning: empty required content area]

Listener Configuration

It is possible to have any number of listeners running and each must have its own configuration like the sample below.

1listeners:
2    # listener configurion block 
3    listener-id:
4      name: "ENV_VARIABLE"
5      pool-size: 20
6      prefix: "my-prefix"
7      shutdown-timeout: 300
8      visibility-timeout: 120
9      poll-wait: 20
10      dlq-suffix: "-dlq"
11      retry: 5
12      type: sqs   

Language: java

Name: Example

Description:

[Warning: empty required content area]

Property

Required

Description

Default Value

listener-id

yes

Actual id of the listener. This must match the id defined at the class when using @ListenerInfo.

n/a

name

yes

Name of the environment variable that will contain the real queue name.

Empty String

type

yes

Type of the listener. This is based on a list of supported listeners of the Connect commercetools-connector.

NOT_DEFINED

fluent-account

yes

Fluent account name. This is required and restricts the processing of messages to services and configuration for said account.

n/a

pool-size

no

Number of threads available to process messages from the queue. Determines how many messages can be processed in parallel

10

prefix

no

Prefix given to the threads processing messages.

default

shutdown-timeout

no

Wait time in seconds to allow in-flight threads to gracefully finish processing before forcing them to quit

300

visibility-timeout

no

Queue visibility timeout in seconds - Messages read from the queue and kept invisible to other listeners while the node that took the message processes it. If the message is not deleted before the timeout the message is made available again for processing - retry in case of errors.

120

poll-wait

no

Listener wait time in seconds to read as many items from the queue as possible.

10

dlq-suffix

no

Dead letter queue suffix. DLQ is a generated name from the queue name with the suffix appended to the end.

-dlq

retry

no

Queue retry policy. How many times the message is put for retry on the queue before it goes to DLQ.

2

max-allowed-pull-size

no

Max number of allowed messages to pull from the queue.

10

props

no

Additional listener configuration. Connect commercetools-connector will read all configuration set under props and have them stored as a Map.

n/a

Job Scheduler Configuration

The commercetools-connector doesn't have an internal scheduler, and it depends on external systems to trigger an HTTP request for a job to be executed as described below.

1PUT https://<domain>/api/v1/fluent-connect/scheduler/add/<fluent-account>/<fluent-retailer>/<job-name>

Language: plain_text

Name: Trigger HTTP request

Description:

[Warning: empty required content area]

All job requests require 3 parameters:

  • fluent-account: Fluent account name
  • fluent-retailer: Fluent retailer id
  • job-name: The name of the handler that will execute the job

For example:

1PUT https://localhost:8080/api/v1/fluent-connect/scheduler/add/cnctdev/1/batch-inventory-sync

Language: plain_text

Name: Example

Description:

[Warning: empty required content area]

The execution of a job is performed asynchronously and the HTTP request returns 200 OK.

All jobs in the commercetools-connector share the same pre-execution and post-execution steps:

  • A job cannot have multiple instances running simultaneously
  • Retrieves the job configuration from Fluent settings
  • Calculate a date range (from-to datetime) the job may use during its execution
  • Execute the actual job
  • Persist the calculated date range as part of the job configuration, so it can be utilised on the next execution
  • commercetools-connector runs at UTC time.

There are 2 kinds of configuration for a job:

  • Runtime configuration
  • Kept at Fluent as settings
  • The configuration key of a job is determined dynamically by taking the 
    `config-prefix`
     and appending the job name at the end. With the template below, config-prefix once configured would have the value of 
    `fc.connect.my-sample-connector.data-sync`
     for example. Combining this with the job name, the final configuration key would be 
    `fc.connect.my-sample-connector.data-sync.batch-inventory-sync`
    .

`1 job-scheduler: 2 config-prefix: "fc.connect.<connector-name>.data-sync"`

Every job gets a pre-calculated date range and this is provided by the commercetools-connector to any job handler as part of the job context. This date range allows the job to work with data in delta mode (if required), only fetching/processing items that have changed since the last execution of the job.

Below is an example of a configuration with no previous execution and some properties in 

`props`
. The date 
`previousEndDate`
 is not mandatory. Whenever there is no valid date set at 
`previousEndDate`
, the commercetools-connector considers the job never ran before and the start date used by the job is EPOCH time. When configuring the job for the first time, if there is a need that its first execution uses a specific start date for the calculated date range then set the desired date at 
`previousEndDate`
.

1{
2    "previousEndDate": "",
3    "props": {
4        "fluentNetworkRef": "BASE_67"
5    }
6}

Language: json

Name: Example

Description:

[Warning: empty required content area]

The date range works in the following way:

  • First execution (with no date set at 
    `previousEndDate`
    ) - From: Epoch time, To: Now
  • First execution (with a date set at 
    `previousEndDate`
    ) - From: date set at 
    `previousEndDate`
    , To: Now
  • Any subsequent execution - From: Last execution end datetime (
    `previousEndDate`
    ), To: now

If the commercetools-connector runs a daily job with the configuration above, the result of the first execution would be as shown below. As the job starts executing, 

`previousEndDate`
 is set to the server’s current datetime (in UTC). The calculated date range used by the job is also saved at 
`lastRun.param.start`
 and 
`lastRun.param.end`
 - note the correlation of 
`lastRun.param.end`
 and 
`previousEndDate`
.

1{
2  "previousEndDate": "2022-09-22T03:00:00",
3  "props": {
4    "fluentNetworkRef": "BASE_67"
5  },
6  "lastRun": {
7    "param": {
8      "start": "1970-01-01T00:00:00",
9      "end": "2022-09-22T03:00:00",
10      "props": {
11        "fluentNetworkRef": "BASE_67"
12      }
13    },
14    "jobStart": "2022-09-22T03:00:00",
15    "jobsEnd": "2022-09-22T03:05:00",
16    "status": "SUCCESSFUL"
17  }
18}

Language: json

Name: Example

Description:

[Warning: empty required content area]

The next day the job runs again, the current value of 

`previousEndDate`
 is used as the start date 
`lastRun.param.start`
 and a new date are set for both 
`lastRun.param.end`
 and 
`previousEndDate`
.

1{
2  "previousEndDate": "2022-09-23T02:00:00",
3  "props": {
4    "fluentNetworkRef": "BASE_67"
5  },
6  "lastRun": {
7    "param": {
8      "start": "2022-09-22T03:00:00",
9      "end": "2022-09-23T02:00:00",
10      "props": {
11        "fluentNetworkRef": "BASE_67"
12      }
13    },
14    "jobStart": "2022-09-23T02:00:00",
15    "jobsEnd": "2022-09-23T02:05:00",
16    "status": "SUCCESSFUL"
17  }
18}

Language: json

Name: Example

Description:

[Warning: empty required content area]

It is also possible for a user to override the normal job operation described above by providing a custom date range. These user-specified dates in UTC are only used once and will not be taken into account for subsequent executions.

1{
2  "customDateRange": {
3    "start": "2022-04-22T00:00:00",
4    "end": "2022-04-23T00:00:00"
5  },
6  "previousEndDate": "2022-09-23T02:00:00",
7  "props": {
8    "fluentNetworkRef": "BASE_67"
9  },
10  "lastRun": {
11    "param": {
12      "start": "2022-09-22T03:00:00",
13      "end": "2022-09-23T02:00:00",
14      "props": {
15        "fluentNetworkRef": "BASE_67"
16      }
17    },
18    "jobStart": "2022-09-23T02:00:00",
19    "jobsEnd": "2022-09-23T02:05:00",
20    "status": "SUCCESSFUL"
21  }
22}

Language: json

Name: Example

Description:

[Warning: empty required content area]

After the job runs with the custom dates, the custom range is removed and 

`previousEndDate`
 remains as it previously was so the job resumes its normal operation.

1{
2  "previousEndDate": "2022-09-23T02:00:00",
3  "props": {
4    "fluentNetworkRef": "BASE_67"
5  },
6  "lastRun": {
7    "param": {
8      "start": "2022-04-22T00:00:00",
9      "end": "2022-04-23T00:00:00",
10      "props": {
11        "fluentNetworkRef": "BASE_67"
12      }
13    },
14    "jobStart": "2022-09-24T02:00:00",
15    "jobsEnd": "2022-09-24T02:05:00",
16    "status": "SUCCESSFUL"
17  }
18}

Language: json

Name: Example

Description:

[Warning: empty required content area]

While the job is running, a temporary property called 

`executionStart`
 is added to indicate the job is running, and it is removed when the job completes.

1{
2  "previousEndDate": "2022-09-23T02:00:00",
3  "executionStart" : "2022-09-24T02:00:00",
4  "props": {
5    "fluentNetworkRef": "BASE_67"
6  },
7  "lastRun": {
8    "param": {
9      "start": "2022-04-22T00:00:00",
10      "end": "2022-04-23T00:00:00",
11      "props": {
12        "fluentNetworkRef": "BASE_67"
13      }
14    },
15    "jobStart": "2022-09-24T02:00:00",
16    "jobsEnd": "2022-09-24T02:05:00",
17    "status": "SUCCESSFUL"
18  }
19}

Language: json

Name: Example

Description:

[Warning: empty required content area]

Property

Description

customDateRange

Optional date range a user can set to override the jobs current 'previousEndDate'. This is only used once and gets removed after a successful execution.

customDateRange.start

Custom user date range start datetime.

customDateRange.end

Custom user date range end datetime.

previousEndDate

Used to keep track of the last execution date. This drives how the commercetools-connector calculates the next date range execution. Whatever the value is set here, this is used as the next start date. If this is missing or invalid, epoch is as the start date. The end date is always the current time the job is executed.

props

Optional job settings.

lastRun

Keeps a copy of the last execution parameters, date range used as well as job execution times.

lastRun.param.start

Last execution date range start.

lastRun.param.end

Last execution date range end.

lastRun.param.props

Last execution props.

lastRun.jobStart

Last execution date time the job start running.

lastRun.jobsEnd

Last execution date time the job finished running.

lastRun.status

Last execution status of how the job finished: FAILED / SUCCESSFUL.

  • Build configuration
    • Kept part of the deployable artifact (yaml file properties, for example)
    • Every Connect commercetools-connector handler has access to optional configuration (props) that are part of the route setup. This is covered in more detail in the Handler Configuration of the customisation guide.
1routes:
2    - name: "fc.connect.batch-inventory-sync"
3      handler: "BatchInventorySyncJob"
4      props:
5        page-size: 500

Language: xml

Name: Example

Description:

[Warning: empty required content area]

General configuration

At a minimum, the commercetools-connector expects the following configuration.

1connector-name: commercetools
2configuration:
3    base-path-key: "fc.connect.<connector-name>"
4    account-mapping-key: "fc.connect.<connector-name>.account-mapping"
5    general-key: "fc.connect.<connector-name>.general"

Language: java

Name: Example

Description:

[Warning: empty required content area]

Property

Description

connector-name

This is the name of the connector and this property is used to both name the connector as well as build the path of other configuration keys. Keep characters limited to 'a-z' and '-'.

base-path-key

Used to fetch all configurations of a Fluent account-retailer based on path. Any custom configuration must adhere to the format otherwise it will not be found.

account-mapping-key

Maps a Fluent account-retailer to an external system. The identification of the external system must be unique and it is possible to be a composite value.

general-key

Any general settings that don't quite fit in any category.

log-level-key

Global level setting key to control the log level (DEBUG, INFO, WARN, ERROR) of the commercetools-connector. Changes to this property will take effect on the first configuration refresh in the commercetools-connector.

Account Mapping Example

1{
2    "fluent": {
3        "accountId": "FCTDEV",
4        "retailerId": "100"
5    },
6    "externalAccount": {
7        "projectKey": "my-project-qa",
8        "uid": "123"
9    }
10}

Language: json

Name: Example

Description:

[Warning: empty required content area]

General Settings Example

1{
2    "productCatalogue": {
3        "entityRef": "PC:MASTER:100",
4        "entitySubType": "MASTER"
5    }
6}

Language: json

Name: Example

Description:

[Warning: empty required content area]

Copyright © 2024 Fluent Retail Pty Ltd (trading as Fluent Commerce). All rights reserved. No materials on this docs.fluentcommerce.com site may be used in any way and/or for any purpose without prior written authorisation from Fluent Commerce. Current customers and partners shall use these materials strictly in accordance with the terms and conditions of their written agreements with Fluent Commerce or its affiliates.

Fluent Logo