Connector requirements for public release (Boomi Technology Partners)

To help you successfully build a connector using the Connector SDK and ensure it is ready to be submitted for approval to be made public in the Boomi Enterprise Platform, follow these requirements.

Important: These requirements must be followed for a connector to be approved by and publicly released (visible to all users) as part of the Boomi Technology Partner Program. Otherwise, your request may be declined. Although not required for a private connector, these recommendations are still highly advisable.

Cloud restrictions

• clouds use the java SecurityManager with a high-security policy, restricting actions on clouds.
• Accessing files within the cloud is restricted. For more information, see the topic Connector cloud permissions.
  • Account-specific files in the cloud are available (this is generally provided by the AccountConfig).
  • The configured temp directory may be used, but the resources must be cleaned up.

Compilation

• Runtimes support Java 8 and 11. Connectors built by partners must be compiled against Java 8 unless otherwise approved by the product team to be compiled with Java 11.
• Partner-built connectors that are submitted to be public must be released versions, not SNAPSHOT.
• Each submitted version of a connector should have a unique version number.

Dependency Management and Packaging

• Dependencies that are already packaged with the Atom should not be packaged with the connector, especially if it is a different version that what the Atom provides. Otherwise, class loading issues can be encountered. To see a list of libraries packaged with the Runtime, see the topic Connector packaging. If a Runtime dependency needs to be overridden with a different version, an overrides file needs to be added in the meta-inf folder.
• The Connector configuration file should not reference a different version of the Connector SDK than what is being used to compile the connector. Otherwise, errors can occur.
• Do not use internal Atom APIs in connectors.

Executions

• Only implement retry logic if necessary.
• Do not retry operations that are not idempotent or that have no chance of succeeding.
• Do not have a mismatch between the operations defined in the Connector descriptor file and the operations implemented in the connector. If the descriptor defines an available operation, that operation should be implemented in the connector.
• Acknowledge all input documents (TrackedData) using the OperationResponse.
  • If a connector fails to acknowledge an input document, the following error occurs: "Input was lost during operation execution"
  • If a connector attempts to acknowledge the same document multiple times, the following error occurs: "Input <document id> was not outstanding (already marked as finished)"

Listener

• Avoid scenarios that could introduce indefinite blocks (waiting for a connection, loops, etc.) as this may cause issues for other listeners in the same account.
• Use a separate thread to poll/pull messages.

Logging

• Avoid excessive logging of the request/response/browser schema. This data is available for the user and therefore additional logging should not be necessary.
• Do not log account-specific information, sensitive data, or encrypted data (passwords, tokens, etc.)
• Do not use System.out or System.err for logging.
• Do not use e.printStackTrace(); for logging.

Performance

• Avoid looping through the same data multiple times.
• Avoid storing/copying the same data multiple times.
• Avoid unnecessary processing.

Resource Management

• All open resources such as Connections, Session, must be explicitly closed.
• Anything that implements Closeable should be explicitly closed.
• Large data should not be loaded in-memory. If there is no way to consume the data efficiently (streaming, etc.), there should be a size limit on the data held in memory, generally 1 MB or less. The AtomContext interface in the Connector SDK provides access to the TempInputStream and TempOutputStream implementations. These allow you to write data to an intermediate location efficiently. If the data is small, it is held in memory. If it is large (greater than 1 MB), it is flushed to disk automatically.
• Examples of in-memory violations include the following:
  • Streams to String
  • Use of Streams to Byte[]
  • Use of JsonNode (this is in memory)
  • Large strings of data
  • Large Lists / Possibly Unbounded Lists of data
• Inbound Specific Code
  • For example, the ObjectData.getData() stream must be closed.
• Outbound Specific Code
  • Response Streams must be closed/cleaned up.

Sensitive data

• Sensitive data (passwords, secrets, tokens, etc.) must be encrypted and use the encrypted password UI component so the values are not exposed in plain text in the UI, component XML, or Audit Log.
• Make sure there is no logging of account-specific information, sensitive data, or encrypted data (passwords, tokens, etc.)

Thread safety

• Do not use non-thread safe static variables. This includes any mutable data that can be changed between threads.