Policy for Deprecated Configurations

iPaaS Documentation General
1

Table of Contents

  • Purpose
  • Why the Configurations Become Deprecated
  • Examples of Deprecated Configurations and Their Replacements
  • The Logic of Value Condition Filter

Purpose

This guide explains the policy of deprecated configurations and how they should be treated.

Why the Configurations Become Deprecated

Prototypes are marked as deprecated when we want to improve or simplify the way those prototypes work but when we cannot do this without breaking backward compatibility. As for now, these deprecated prototypes are not deleted and will be kept with the mark [deprecated].

However, it is intended to automatically set up automatic updates for the configurations of clients to the new versions in the future.

Examples of Deprecated Configurations and Their Replacements

  1. [Deprecated] Filesystem CSV Subscriber - has been replaced with Filesystem: listing subscriber.
  2. [Deprecated] Filesystem XML Subscriber - has been replaced with Filesystem: file subscriber.
  3. [Deprecated] Json: Decode to object - has been replaced with Serialize/Deserialize JSON.
  4. [Deprecated] Oauth2 authentication - has been replaced with Oauth2 authentication.
  5. [Deprecated] Value condition - has been replaced with Value condition.

The Logic of Value Condition Filter

The logic of the Value condition filter was changed. Let’s say you want to execute a transformer, but only when a field matches a value (e.g. name = foo). The deprecated condition would still execute the transformer when this field is not available in the data. This logic has been changed in the new version so that the transformers are only executed when the field is available and matches the value.