version 2.0

1. Certification Process

MuleSoft has expanded the Anypoint™ Connector platform enabling partners, from the MuleSoft Partner Program, and third-party development groups, to develop Anypoint™ connectors.

Every connector in the MuleSoft Anypoint™ Platform must go through a mandatory MuleSoft Basic Connector Certification Process before final release. This certification process was conceived to assess the overall quality of all available connectors, ensuring that every connector published on the Anypoint™ Exchange follows industry best practices. As a result of this certification process, we are able to define a high quality threshold for every Anypoint™ connector available on the MuleSoft platform.

All available connectors, built either by our partners or internal development team, go through MuleSoft’s Basic Certification Process, which is carried out by MuleSoft’s internal team. Once a connector passes basic certification, it is published in Anypoint Exchange.

The scope of this process mainly depends on the composition of the connector, where a more complex connector will require further steps in the certification process. Our certification approach aims at testing every functional block of the connector prior to release.

This document first introduces the entire Connector Lifecycle Model, which includes four different stages: On-board, Development, Certification and Publishing.

  1. On-board: Takes into consideration the legal engagement between a third-party development group or partner, and MuleSoft.

  2. Development: The development stage, considering strictly testing methodologies.

  3. Certification: The certification process per-se, carried out by a MuleSoft.

  4. Publishing: Covering the final deployment of the certified connector within Anypoint Exchange.

Of these stages, we only take into consideration the second and third: Development and Certification. The first stage is out of the scope of this document, while the last one hardly requires involvement from the developer’s side and therefore it will not be mentioned here.

2. Coding Standards and Best Practices

Development best practices and coding standards have been included within the connector development community over time, leading to connector quality improvements. During the certification process, most of these practices and standards are checked by automated tools, such as SonarQube.

2.1. Anypoint™ Connector DevKit Version

The last version of Anypoint™ Connector DevKit must be used to develop your connector. As of December 2015, the latest stable DevKit version is 3.8.0.

DevKit 3.8.0 ensures that a connector will be compatible with Mule ESB 3.5.x, Mule ESB 3.6.x and Mule ESB 3.7.x. However, external libraries employed by the connector might have conflicts with different Mule ESB versions. Sanity checks are mandatory for every Mule ESB version.

2.2. Connector Category

A connector should define its category in its POM properties:

<groupId>org.mule.modules</groupId>
<artifactId>mule-module-sample-connector</artifactId>
<version>1.0.0-SNAPSHOT</version>
<name>Mule Sample Connector </name>
<packaging>pom</packaging>

<properties>
    <category>Certified</category>
    <licensePath>LICENSE.md</licensePath>
    <devkit.studio.package.skip>false</devkit.studio.package.skip>
</properties>

  • For MuleSoft Certified Connectors (if you’re a partner building a connector, this is your connector’s category) DevKit 3.7.2 or above requires you to use Certified in the category.

  • For Select connectors, please use Select as the category.

  • For Premium connectors, please use Premium as the category.

Using this as a reference, please use <category></category> as the element for indicating the category.

All connectors except Community require that you include the @RequiresEnterpriseLicense attribute to the connector. In addition, if you are building a paid connector as a MuleSoft Certified connector, DevKit 3.8.0 or above supports license validation natively, but you can also use your own license validation mechanism and make sure that you enforce the legal use of your connector in the way you see fit.

MuleSoft will not be liable for errors in your code that could lead to people using your connector without a proper license.

For Select or MuleSoft Certified Connectors

@RequiresEnterpriseLicense(allowEval = true)
public class SalesforceConnector {

For Premium Connectors

@RequiresEnterpriseLicense(allowEval = true)
@RequiresEntitlement(name = "oracleebs-connector")
public class OracleEBSConnector {

2.2.1. Distribution Management

Configuration of the distributionManagement element varies from connector to connector, depending on its category and the project structure.

  1. Certified:

    <distributionManagement>
    <repository>
        <id>mule-ee-releases</id>
        <name>MuleEE Releases Repository</name>
        <url>https://repository-master.mulesoft.org/nexus/content/repositories/releases-ee/</url>
    </repository>
    <snapshotRepository>
        <id>mule-ee-snapshots</id>
        <name>MuleEE Snapshots Repository</name>
        <url>https://repository-master.mulesoft.org/nexus/content/repositories/ci-snapshots/</url>
        <uniqueVersion>false</uniqueVersion>
    </snapshotRepository>
</distributionManagement>

  2. Multi-Module Certified Connector:

    If a MuleSoft Certified connector is part of a multi-module project, before the release verify that:

    • The connector’s module is deployed to the private nexus (same distribution management as described above for Standard, CI-releases).

    • The parent pom and other non-connector modules of the multi-module project have the same distribution management as described above for public or Community connectors.

For example, in a project with a parent pom, a utils module and a connector module, if and only if the connector is Certified, then the parent pom should declare the public distributionManagement, and then it should be overridden in the connectors' pom with the private distributionManagement.

2.2.2. Distribution Management Matrix:

Connector Configuration Certified

https://repository-master.mulesoft.org/nexus/content/repositories/releases-ee/

Single Module

https://repository-master.mulesoft.org/nexus/content/repositories/releases-ee/

Multi Module

Parent, Utils:

http://repository-master.mulesoft.org/releases/

Connector:

2.3. Maven Conventions and Setup

The following section describes a set of conventions and best practices to follow when defining your connector’s Maven configuration.

2.3.1. Best Practices

A connector tested in an isolated environment might not work in a Mule environment. Therefore, different constraints apply:

  • Follow Maven default name conventions.

  • Do not overwrite org.mule.tools.devkit:mule-devkit-parent properties.

  • Do not reference SNAPSHOT dependencies in plugins or dependencies.

2.3.2. Do Not Define Custom Repositories

If your connector makes use of dependencies not available in standard Maven or MuleSoft repos, do not add additional repositories to pom.xml. Adding custom Maven repositories could cause several issues when the Mule application is mavenized. If you require this type of dependency, we will host the dependencies as part of you connector. As part of the hand-off for certification, these JARs need to be provided with all the required info such as groupId, artifactId and version.

2.3.3. Multi Module Layout

In large Maven projects, it is common practice to divide the project into submodules. This means you may end up with a module for your connector and other modules for utils, commons or other kinds of modularized source code that will be consumed by the connector.

Consider the following use case:

Project parent pom

<groupId>org.mule.modules</groupId>
<artifactId>mule-module-sample-connector-parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
<name>Mule Sample Connector Parent</name>
<packaging>pom</packaging>

<modules>
    <module>some-util-lib</module>
    <module>rehusable-service-adapter</module>
    <module>mule-connector-sample</module>
</modules>

In your connector module’s pom.xml:

Connector sibling dependencies

<dependencies>
    <dependency>
        <groupId>org.mule.modules</groupId>
        <artifactId>some-util-lib</artifactId>
        <version>1.0.0-SNAPSHOT</version>
    </dependency>
    <dependency>
        <groupId>org.mule.modules</groupId>
        <artifactId>rehusable-service-adapter</artifactId>
        <version>1.0.0-SNAPSHOT</version>
    </dependency>
</dependencies>

It is important to note that your connector’s pom inherits from mule-devkit-parent, and that each of the other sub-modules inherits from the project parent. Therefore, you will have artifacts inherited from the mule-devkit-parent pom and the connector pom:

<artifactId>some-util-lib</artifactId>
<packaging>jar</packaging>

<parent>
    <groupId>org.mule.modules</groupId>
    <artifactId>mule-module-sample-connector-parent</artifactId>
    <version>1.0.0-SNAPSHOT</version>
</parent>
...
<artifactId>rehusable-service-adapter</artifactId>
<packaging>jar</packaging>

<parent>
    <groupId>org.mule.modules</groupId>
    <artifactId>mule-module-sample-connector-parent</artifactId>
    <version>1.0.0-SNAPSHOT</version>
</parent>
...

Connector pom

<artifactId>mule-connector-sample</artifactId>
<name>Mule Sample Connector</name>
<packaging>mule-module</packaging>

<parent>
    <groupId>org.mule.tools.devkit</groupId>
    <artifactId>mule-devkit-parent</artifactId>
    <version>3.9.0</version>
</parent>

This mix of pom inheritance and aggregation allows you to maintain a general parent pom for your secondary modules, to control the compilation from a single point, while providing the connector with the required devkit-parent pom, ensuring that all the other modules will be installed in your local repository before building the connector.

In multi-module projects, the deployment of the artifacts vary depending on the connector "category". Rule-of-thumb is that the parent pom and all the secondary modules (not the connector module) should be deployed to a public nexus repository, while the connector artifact will override its parent dependency management configuration with its own repository rules.

2.3.4. Avoid Caching

Connectors should not hold state, unless strictly necessary. Several APIs are actually hosted in cloud environments, and therefore caching states ends up exposing untrusted data in the connector. There are a few cases where the connector might need to save some data from the current API while working on it, which leads to caching.

For scenarios where the connector must use a cache, the following code should be used:

// 1) The connector asks for the manager of the Object Store
@Inject
protected ObjectStoreManager objectStoreManager;

And then the objectStoreManager can get/create a custom Object Store as follow:

// 2) The connector asks Mule for the Object Store represented by a "given ID"
ObjectStore<? extends Serializable> os = objectStoreManager.getObjectStore("given ID");
// 3) The connector uses it
os.store("key", "value");

Another way to cache is to use temporary files, but it might depend on the use case.

2.3.5. Avoid Spawning Threads

Like caching, spawning threads within a connector is not recommended, since the common API lives in the cloud. This means that a connector will not improve its throughput with more threads, because every communication with the API means more HTTP requests/responses. Although we don’t recommend using threads, or caching, there may be custom cases requiring them.

For scenarios where the connector needs to spawn threads you should use a Executor Service.

2.3.6. Reading Resources From Within the Connector

When reading resources that are bundled with the connector, the usual getClass().getResourceAsStream("custom-file-to-read.txt") will work. But, if the file "custom-file-to-read.txt" can actually be parametrized through the Mule application, then there is another mechanism to use.

Consider that for your connector, a file can be fed from the src/main/resources folder (again, this file comes from Studio, not from the connector), the following code should be used:

// 1) The connector asks for the manager of the mule context
@Inject
protected MuleContext muleContext;

which allows the resources to be read as follows:

ClassLoader classLoader = muleContext.getExecutionClassLoader();
URL resourceURL = classLoader.getResource("custom-file-to-read.txt");

Where "custom-file-to-read.txt" is the file to be read from the Mule app in src/main/resources/custom-file-to-read.txt.

2.3.7. Mule Dependencies

Adding dependencies to your connector should be carefully considered, since they might collide with Mule. A few constraints apply:

  1. When adding Mule artifacts, always use <scope>provided</scope>.

  2. When adding artifacts that might collide with Mule, choose versions that are in the current Mule versions, for what your connector is going to work with. Some of those artifacts are: cxf, jersey, spring, guava, etc.

2.3.8. Shading

For some corner cases, you might need to add a dependency that does collide with Mule either directly or in a transitive dependency. For those scenarios, we strongly recommend using the same version of the library as Mule does or, if possible, change your library to another equivalent. If none of the options above are available, and you still need that custom library that collides with Mule, then shading could work for you. Support for shading has been added in Devkit 3.5.3.

You need to modify your connector’s pom.xml file to add the shading plugin in order to achieve two things: 1) add the custom jar into the connector and 2) rename the packages of the library into a new one in order to avoid collisions.

For simple cases, were the colliding libraries are explicitly declared (for example, you require a different jersey version than the one packaged with Mule), shade only those dependencies.

The following snippet should work when using a library with the groupId org.some.library and the artifactId custom-artifact-id

<dependencies>
    <dependency>
        <groupId>org.some.library</groupId>
        <artifactId>custom-artifact-id</artifactId>
        <version>${some.lib.version}</version> <!-- version to be included in the connector jar -->
        <!-- default scope is required-->
    </dependency>
</dependencies>

<!- rest of the configuration -->

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <!-- custom shade configuration -->
                <artifactSet>
                    <includes>
                        <include>org.some.library:custom-artifact-id</include>
                    </includes>
                </artifactSet>
                <relocations>
                    <relocation>
                        <pattern>org.some.library</pattern>
                        <shadedPattern>org.some.${some.lib.version}.library</shadedPattern>
                    </relocation>
                </relocations>
             </configuration>
        </plugin>

        <!-- Other plugins -->
    </plugins>
</build>

Some other cases are more complex, since the issue appears with a transitive dependency. Let’s say you need an sdk my-sdk that uses some other dependency common-lib internally, and then if Mule uses an incompatible version of this common-lib, a classloader issue might result. For this case, you need to shade not only the sdk, but also the transitive dependency, that will now be explicitly declared as follows:

<dependencies>
    <dependency>
        <groupId>org.some.library</groupId>
        <artifactId>custom-artifact-id</artifactId>
        <version>${some.lib.version}</version> <!-- version to be included in the connector jar -->
        <!-- default scope is required-->
    </dependency>

    <dependency>
        <groupId>com.commons.lib</groupId>
        <artifactId>commons-utils</artifactId>
        <version>${common.utils.version}</version> <!-- version used by the sdk -->
        <!-- default scope is required-->
    </dependency>
</dependencies>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <!-- custom shade configuration -->
                <artifactSet>
                    <includes>
                        <include>org.some.library:custom-artifact-id</include>
                        <include>com.commons.lib:commons-utils</include>
                    </includes>
                </artifactSet>
                <relocations>
                    <!-- as a best practice, rename packages using the dependency version-->
                    <relocation>
                        <pattern>org.some.library</pattern>
                        <shadedPattern>org.some.${some.lib.version}.library</shadedPattern>
                    </relocation>
                    <relocation>
                        <pattern>com.commons.lib</pattern>
                        <shadedPattern>com.commons.${common.utils.version}.lib</shadedPattern>
                    </relocation>
                </relocations>
             </configuration>
        </plugin>
    </plugins>
</build>

Further explanation regarding the maven-shade-plugin can be found here.

2.3.9. Connector Structure

If you create your connector project using the DevKit Studio Plugin, the generated project directory layout is the recommended approach. If you are interested in more details, the project directory structure is described here.

In order to provide automated enforcement of these rules, the following plugin must be configured as part of the connectors pom.xml. We will be responsible for validating the project structure.

Copy and paste the following snippets into your connector pom.xml:

<build>
    ...
    <plugins>
        ...
       <plugin>
            <groupId>org.mule.certification</groupId>
            <artifactId>project-structure-validation</artifactId>
            <version>1.0.6</version>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>validate</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        ...
    </plugins>
    ...
</build>

2.4. DevKit Standards and Best Practices

2.4.1. DataMapper Compliance

To have the best experience in Anypoint™ Studio, connectors must be DataMapper-compliant. To achieve this, all operations must follow these recommendations.

Any argument, returned or received, must be one of the following data types:

  • Map

  • POJO

  • List<Map>

  • List<String>

  • List<POJO>

  • List<List<String>>

These types must be part of the method signature so that DataMapper can auto-recognize the types in it’s mapping UI.

Important

Only use a map if you cannot use a POJO.

Use a map only if your data:

  1. Is schema-less, for example if created using MongoDB.

  2. Has user customizable schemas, if created with Salesforce.

  3. Has unknown content.
Good Example Bad Example

List<Map> query()

List<DBObject> query

void send(Invoice invoice)

void send(Object object)

Invoice getInvoice(String id)

Object get(String id, Class typeToCreate)

All operations must have a single object to take input from DataMapper. The object must be a single object, not multiple arguments. This object is called the Primary argument.
Good Example Bad Example

void createInvoice(Invoice invoice)

createInvoice(Header header, List<LineItems> lineItems)

void upsert(List<Map> sobjects, String type, String externalFieldId)

N/A - Multiple arguments are still needed!

GetTaxResult getTax(TaxRequest request)

public GetTaxResult getTax(String companyCode, AvalaraDocumentType docType, @Optional String docCode, Date docDate, @Optional String salespersonCode, String customerCode, @Optional String customerUsageType, String discount, @Optional String purchaseOrderNo)

2.4.2. Java Version

A connector needs to define its target JDK version according to its compatibility with Mule runtimes. Mule runtimes 3.5.X must use Java 1.6, Mule runtimes 3.6.X must use Java 1.7, Mule runtimes 3.7.X must use Java 1.7 and Mule runtimes 3.8.X must use Java 1.7/1.8. This can be achieved by overwriting the POM property <jdk.version> with the desired version.

2.4.3. Annotations

If you have multiple arguments, annotate the Primary argument with:

@Default("#[payload]")

This way DataMapper knows which argument in the operation to use for mapping.

2.4.4. No Warning During Compilation

DevKit does a intensive analysis of the used annotations and semantic of them in conjunction with others. It’s important the code is free of compilation warning to help on the maintainability of the code and to follow good practices.

2.4.5. DevKit Generated API Doc

Connector documentation is composed of two different types of documentation: DevKit Generated API Doc and the Connector Documentation.

DevKit API Doc is automatically generated by DevKit using the JavaDoc documentation in the connector class. This is one of the most important information sources used by the developer when using the connector.

2.4.6. Connector Code Convention

We provide a file with a recommended code styling format for connectors. This is an important aspect of the connector code quality and most of the connectors use this standard format. This style can be imported in Eclipse, Studio and IntelliJ.

Download the Connector Style Format here.

2.4.7. @Config Friendly Name Conventions

In order to provide consistency across all the connectors, Global Element default name should a follow a convention:

  1. If there is one single configuration, "Configuration" should be used as friendlyName

  2. If there is more than one configuration, the following convention should be followed:

    1. "OAuth 2.0" for OAuth configurations

    2. In other cases, use a brief description following the same terminology used in the system to integrate.

GlobalElement name is configured using the friendlyName attribute of the configuration class.

2.5. Connector Demo Example

A Mule application’s endpoints allow a user to interact with the service and API using the connector. Endpoints are committed to the GitHub repository along with source code. Use services or API use cases to determine which connector operations to select.

Guidelines to follow:

  • All demo projects must be isolated in a folder with a descriptive name (It does not matter if is just only one demo). Eg: https://github.com/mulesoft/magento-connector/tree/develop/demo

  • Use a meaningful name for the project. Avoid things such as "my-connector-demo" or "example-1". This name will be displayed in the ApiDoc site. Eg: http://mulesoft.github.io/salesforce-connector/

  • The demo name must have middle lines to separate the words in it and must be in lower case. example: "mail-service-demo"

  • Don’t add prefix such as "mule" or "app". Just the purpose of it.

  • Ensure that an app can be run by entering credentials without additional configuration or connector installation.

  • Use placeholders for credentials.

  • Ensure that flow names and message processors display names that make the use case easy to understand.

  • Provide instructions on how to run the app in a README file (for example, S3). It is recommended to add in a description of the demo application, such as what it aims to demonstrate and what each step of the demo is responsible for. Where application, you can also mention where your demo fits in a larger use case.

  • Expose a set of endpoints that the user can access following the steps in the README to reproduce a use case.

  • Consider implementing a CRUD (or similar) use case with chained processors whose payloads get logged into the Studio console (for example, S3).

  • Use DataWeave for Premium, Select or MuleSoft Certified connectors' CRUD (or a similar) use case if API methods attributes and/or return types allow it.

  • Consider basic error handling in the Mule app.

There are two kinds of demos that you can create:

  • Single operation demos

  • Workflow demos

Single operation demos are used to invoke just one operation in the connector. Workflow demos are used to invoke a number of operations in the connector sequentially. These aim to show a simple usecase of the connector, such as a normal CRUD workflow. We provide two templates to help you create an interface for your demo, one for each kind of demo. You can find the template for single operation demos here and the template for the workflow demos here.

The demo HTML pages above make use of Twitter Bootstrap to present a clean interface to the user. You should base your demo on this template. If you are not familiar with the Twitter Bootstrap library, it is highly suggested to look at their documentation page. Single operation demos only provide a form, whereas workflow demos provide an accordion, where one step leads to the next. In the latter case, any values retrieved by the first step should be used to autofill values in the second step where possible.

As an example, let us take a CRUD workflow for a number of Twitter API calls. The first step will create a tweet and return a number of values pertaining to the tweet that was created. One of these values would be the Tweet ID. The second step would be the "read" operation. The tweet ID should be automatically filled in the second step so that the user is simply able to submit a "read" API call without any needed input. The final step of the workflow should present an alert (or a notification of some sort), that the workflow has ended, outputting any relevant information from the last step. An example of this would be a "Tweet Deleted" message if the workflow was completed successfully, and the tweet that was created in the first step is successfully removed.

The following code snippets explain some parts of the above HTML page. The demo contains 3 parts:

  • The JavaScript that handles asynchronous calls to the demo running on a Mule instance.

  • The CSS that renders the HTML page

  • The HTML itself

The JavaScript

The JavaScript for this demo is simply used to send AJAX calls to a Mule server that hosts your demo application. In the case of workflow demos, it is also used to collapse the accordions as the user goes from one step to the next.

Initially, a reference to the <div> and <form> elements is obtained.

var createDiv   = $('#createDiv');
var readDiv     = $('#readDiv');
var updateDiv   = $('#updateDiv');
var deleteDiv   = $('#deleteDiv');

var createForm  = $('#createForm');
var readForm    = $('#readForm');
var updateForm  = $('#updateForm');
var deleteForm  = $('#deleteForm');

Then, each form is paired with a jQuery function sends an AJAX request whenever a form is submitted.

createForm.submit(function() {
  $.ajax({
    type: 'POST',                             // Submit an HTTP POST request
    url: '/create',                           // The URL where your endpoint is listening
    data: createForm.serialize(),             // Serialized form URL-encoded input
    success: function(data) {                 // Success function called if request succeeds

      $('input[name=message]').val(data.message); // Autofill data in the next workflow step as needed

      createDiv.collapse('hide');             // Hide current accordion window
      readDiv.collapse('show');               // Show next accordion window
    },
    error: function(request, status, error){  // Error function is executed if an exception occurs in the flow
      alert(request.responseText);            // Alert the user of any errors
    }
  });

  return false;                               // Let jQuery handle the form submission
});

In the case of a workflow demo, every form will represent a step in the workflow. The above code snippet should be repeated for every form you have in your workflow, applying changes as needed.

The CSS

The HTML page linked above comes with a number of CSS presets that you can use throughout your demo. A number of Bootstrap CSS classes are also used to build the accordion and the panels within it. For more information on how to build your own accordion, or even extend the one in the HTML template, please refer to the Bootstrap Accordion documentation page.

The HTML

This part is what ties everything together. The HTML represents what your users will see when they open your demo to use your connector. Take this HTML snippet as an example:

<div class="panel-group" id="accordion">
    <div class="panel panel-default">
        <div class="panel-heading">
            <h2 class="panel-title demo-heading">
                <a data-toggle="collapse" data-parent="#accordion" href="#createDiv">Create</a>
            </h2>
        </div>
        <div id="createDiv" class="panel-collapse collapse in">
            <div class="panel-body">
                <form id="createForm" class="demo-form" role="form" >
                    <label>Message</label>
                    <input type="text" name="message" value="Hello from Mule!" required class="form-control" ><br>
                    <input class="btn btn-lg btn-primary btn-block" type="submit" value="Create"><br>
                </form>
            </div>
        </div>
    </div>
    ...
</div>

The above snippet of HTML is taken from the workflow demo template, it represents a single panel in the accordion. This panel is split into two parts: the header and the content. The header refers to the content through the anchor tag (<a>). When this header is clicked, the content is shown. On the other hand, the content is composed of a simple form that is used to submit requests to Mule. These requests are handled by the JavaScript shown above.

For a complete example of a workflow demo, you can download a sample project that uses MongoDB here.

2.6. Third-Party Licenses

As part of the certification, it’s important to validate that all the libraries used by the connector are Open Source friendly. A easy way to generated a report of this, is running the following command:

mvn org.codehaus.mojo:license-maven-plugin:1.8:aggregate-add-third-party

The current list of licenses approved for use by third-party code redistributed with Community Connector projects is:

  • Apache Software License 1.1

  • Apache Software License 2.0

  • W3C Software License

  • Common Public License Version 1.0

  • IBM Public License 1.0

  • Mozilla Public License Version 1.1

  • Common Development and Distribution License (CDDL) Version 1.0

  • GNU Free Documentation License Version 1.3

  • BSD

  • MIT

Licenses that are not approved for use include:

  • GNU GPL 2.0

  • GNU LGPL

  • Sun Binary Code License Agreement

2.6.1. Open Source Compliance Checklist

Check that :

  • No not approved for use third-party libraries are been distributed with your project

  • There are no dependencies with no license

  • Approved third-party are compliant with their license requirements

2.7. Connector Icon

We recommend your connector have a consistent look-and-feel with existing connectors in Anypoint Studio. You can replace existing icons in {your connector project}/icons with proper ones.

Example: Slack Connector

Slack Small Icon

slack connector 24x16
Figure 1. Slack Small Icon

Slack Large Icon

slack connector 48x32
Figure 2. Slack Large Icon

2.8. LICENSE_HEADER.txt

DevKit requires that your source files contain a license header. To apply the license header to every source file in your project, run the following command in a command console at the root of your project, which contains your connector project’s pom.xml file:

mvn license:format

Example: LICENSE_HEADER.txt for MuleSoft Salesforce Connector

(c) 2003-2016 MuleSoft, Inc. The software in this package is published under the terms of the Commercial Free Software license V.1, a copy of which has been included with this distribution in the LICENSE.md file.

3. Documentation & Release Notes

Documentation is a vital part of the development stage. Your development team must strictly follow Mulesoft documentation standards described in this document.

3.1. Built-in Documentation

Part of the documentation must be packaged within the connector source code. The mandatory files are:

  1. User Guide

  2. Release Notes

  3. README

In addition, create a folder named images_ for image resources used in the documentation, one called attachments_ for user-downloadable content such as a JSON file or WSDL XML file, and one called _sources for management of any code samples presented in the connector documentation, especially those which have associated Mule flow screenshots. It is important to give the corresponding image and Mule XML code the same name. The only thing that should differ are the file extensions, for example, connector-flow`.img` and connector-flow`.xml`.

3.2. User Guide

The user guide needs to be fully descriptive and easy to read, including not only technical documentation but use cases and error solutions. Write the documentation using AsciiDoc syntax so that the resulting file is called user-manual.adoc. Closely follow the template found here. It should reside in doc folder in the root of the connector project.

3.3. Release Notes

Release notes need to be highly descriptive, including backward compatibility of the released connector with previous versions. Closely follow the template found here. It should reside in doc folder in the root of the connector project.

3.4. README

A README.md template can be found here. It should reside in the root of the connector project.

3.5. Connector APIdoc

Each connector requires:

  1. A description that provides a clear and a complete explanation of its purpose.

  2. XML samples of connector Configs (connection configurations) and Processors (the code that backs connector operations)

  3. Attributes that affect connector method behavior must be documented in detail.

For further information, refer to:

Salesforce Connector APIDoc.

4. Appendixes & Templates

4.1. Connector Project Directory Layout

4.2. Common Public Attribution License Version 1.0 (CPAL)