This document briefly describes the decisions and steps required to start an Any point Connector development project to ensure that the connector works and is extended with the required functionality. It can be used as a roadmap for connector development work.
This document assumes that you are familiar with Any point Connector DevKit and have installed the appropriate versions of DevKit, JDK, Any point DevKit Plug-in, and Maven as specified in your development environment setup.
Summary of the joint development process
When developing connectors with DevKit, use cases facilitate a variety of decisions about authentication, connection and process launch on the target, and data transfer to external applications or other sources. These decisions, in turn, determine what you develop. After presenting your options, this document provides information to help you make your decision and provides links to more details.
Step 1: Configure API access
Prepare the Binder test environment. The details vary greatly depending on the target system.
SaaS: For some SaaS applications, the sandbox may be a separate account from the production account or may correspond to a different endpoint.
On-premises: Some on-premises systems or web services may have a separate standalone installation that uses synthetic data instead of production data.
Retrieves an existing document on the target system, e.g. B. an API document.
For detailed instructions, see Configure API Access.
Step 2: Create an Any point Connector project
Follow the process of creating a Java SDK-based plug-in to start the plug-in development project in your development environment.
Add the Java libraries required for the target system, such as B. Client libraries and class libraries delivered to the target system.
Upon completion, you will have a skeleton project containing Java classes with the most basic connector functionality.
Step 3 – Authentication
If your API requires authentication, check the authentication method used by the API and choose an authentication method supported by the connector. Depending on your use case, select an authentication method from the following table. For more information, see Authentication, which lists all supported methods.
Step 4 – Define attributes, operations and data models
Most of the Java code you write for a connector deals with how to call the API as part of a connector transaction, and how the connector passes data between those transactions and Mule. These are the most diverse API-based connectors.
Step 5 – Unit Assembly and Bump Test
Production-ready connectors require a series of the unit and functional tests. The linker uses the standard JUnit framework. In practice, unit tests are created during the implementation of the linker job. Most successful front-end software implementations use a test-driven approach.
Develop at least one mule stream that uses connectors.
Create an instance of FunctionalTestCase and run the test. For DevKit tests, run Mule on the JUnit test case. Each test case you create extends the FunctionalTestCase class (a subclass of JUnit). Test cases manage the lifecycle of a Mule runtime instance and call flows to execute tests.
Programmatically analyze the results of each test case to determine success or failure.
Before we release the connector to the world, we run a full test suite that covers all processes and runs all major code paths. The project created by Maven includes a sample test case in the src/test/java directory to get you started.
For more information about implementing connector test cases with JUnit, see JUnit. Development of connector tests for DevKit.
Step 6 – Document the connection
Documentation is required for fully functional connectors. You can use DevKit to create a reference document complete with code samples.
Every time you add an action to a connector, DevKit adds a sample XML snippet to the source code comment. These code snippets appear in the automatically generated documents of the interface software.
It checks the automatically generated document, decides whether to expand it, and provides more information about a single action than a normal document.
For more information, see the connector reference documents.