Connector Attributes, Operations, and Data Model
Once you have your authentication working, you can start adding functionality to your connector. Adding functionality requires the following steps:
-
Adding configurable attributes that provide state information on the connector that can be used in operations
-
Implementing the operations available on the connector
-
Defining a data model for objects passed into and out of operations on the connector
This document provides an overview of the various approaches to selecting a data model, and introduces the main styles of API access. You will learn to build connectors for each of them in the pages that follow.
Configurable Attributes
Attributes on a connector are like attributes in any Mule element. They are exposed in the connector’s XML configuration element, and configurable in the connector’s property dialog. Internally, they are instance variables on the main @Connector class with getters and setters, so they can be referenced and manipulated in the code of your connector.
One common use for attributes is to provide endpoint details for your connector – for example, to specify whether to connect to a development sandbox endpoint or a production system endpoint.
Details on implementing configurable attributes are discussed in Defining Configurable Connector Attributes.
Static vs. Dynamic Application and Connector Data Models
The underlying data model for the target resource you connect to often drives design decisions about the best way to represent data going to and from your connector. The goal in general is to choose a representation that fits the underlying data, while still supporting the necessary metadata to work with Mule DataSenseTM.
-
Static data models have fixed definitions of all the objects and their attributes supported by the target. Most services, particularly relatively simple ones, implement static data models. For targets using static data models, it is recommended to create Plain Old Java Objects (POJOs) that correspond to the objects exposed through the connector’s operations. Short of a revision to the target APIs, these classes do not need to change in individual deployments.
-
Dynamic data models enable the customization of the application objects and their attributes. Salesforce.com and complex ERP applications often implement dynamic data models so that they can be customized from one customer to the next. In the case of a dynamic data model, it is recommended that you use Java key-value Maps to represent application objects in Mule.
Most of the examples in this document focus on the static data model case, as it is the most common.
API Access Methods and Client Implementation Styles
Most of the Java code you write for your connector relates to calling operations on your target and passing data between those operations and Mule. This is the area that varies most among connectors, and contains the most target-specific code.
Services can expose operations several ways. The most common are summarized in the table below, along with Mule’s recommended client technology for interfacing with them.
| Service API Style | Recommended Approach | Notes |
|---|---|---|
Pre-built Java Client Library |
Using a Client Library |
|
SOAP API |
Apache CXF |
|
RESTful API |
Jersey Client |
|
RESTCall Annotations |
|
Choosing Among Multiple Access Methods
Some services expose multiple APIs accessible via different styles to suit different use cases. For example, an application may have a Java client library that fits the most common use cases, and lower-level RESTful or SOAP APIs that expose more complete functionality with a different model. Choose the one that bets fits your situation.