= XML SDK ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] :keywords: :toc: The XML SDK is an alternative to the more advanced Java-based Mule SDK. XML SDK is for creating custom modules, similar to the way you create a Mule app. In fact, you can use existing Mule components in the module. The framework simply adds a few syntactic idioms as XML elements that enclose the main parts of module, such as ``, ``, and `` elements. For example, this snippet defines a single operation in the `Hello XML SDK`: [source,xml,linenums] ---- ---- You use a Mule SDK component in a Mule flow the same way that you use any other component. In this example, execution of the flow `"random-flow"` sets the payload to `"Hello World!"`, as defined in the operation ``. [source,xml,linenums] ---- ---- Note that the XML SDK is strongly typed, so the data type of defined parameters for every operation is statically set for both the input and output. == Install the Required Software Install and verify that the following tools are working in your local environment: * Java Development Kit 8 (JDK 8) to compile and build your Java code. + NOTE: The maximum supported version for XML SDK is JDK 17, however, you can use JDK 17 only for running your application. Compilation with XML SDK must be done with JDK 8. * Apache Maven 3.3.9 or later to manage your project’s build. == XML SDK Basics An XML SDK component is composed of key elements that delineate both its behavior and the way the runtime interacts with it: * Operations * Properties * The enclosing Module === Operations An `` element defines a set of input parameters and a single output. Like a function, it has input parameters, performs actions (described in the body), and has a single output. Unlike a function, the behavior of an operation can vary if it stores values or references external sources. * Input parameters (``): Declares a type to be entered when calling the operation. + Keep in mind that these parameters are the only data that the message processors in the `` scope can access. + * Body (``): Defines a chain of components to be executed, similar to a flow. * Output (``): Declares the output type of your XML SDK module. This is the type of the payload after it is processed by the ``. * Errors: Declares the error types the XML SDK can raise (or map) within the ``. The following XML SDK module takes two numbers as parameters and has a single operation that sums them together: [source,xml,linenums] ---- ... ---- To use an XML SDK module in a Mule app, you simply add it to a Mule flow, for example: [source,xml,linenums] ---- ---- .Attributes of [%header,cols="20,20,30,70a"] |=== |Name | Use | Default Value | Description | `name` | required | NA | Name of the `` | `defaultValue` | optional | NA | The `` uses the default value if you do not provide another value. | `use` | required | `AUTO` | Possible values: * `REQUIRED`: Parameter must be present. It cannot be REQUIRED if the parameter has a `defaultValue`. * `OPTIONAL`: Parameter is not required. * `AUTO`: Defaults at runtime to `REQUIRED` if `defaultValue` is absent. Otherwise, it is marked as `OPTIONAL`. | `type` | required | NA | Defines the data type of the ``. You can use any primitive type such as `string`, `boolean`, `datetime`, `date`, `number`, `time`, or it can also rely on any type defined in the <>. | `password` | optional | `false` | Marks the `` with `\****` in the UI. | `role` | required | `BEHAVIOUR` | Set of defined roles for a given parameter that modifies the generated XSD for the current ``. * `BEHAVIOUR` renders an attribute. * `CONTENT` implies support for DataWeave in place as a child element. * `PRIMARY` works like `CONTENT` but maps to the payload by default. See xref:content-parameters.adoc[more info on roles]. | `summary` | optional | NA | Adds a small tooltip to the ``. | `example` | optional | NA | Adds a short example of the data type for this parameter. | `displayName` | optional | NA | Provides a UI label. When there is no `displayName`, the default value is a hyphenated version of the `name` attribute. | `order` | optional | NA | Defines an order in which to render each element in the UI. | `tab` | optional | NA | Defines the group (or tab) to which the `` must belong in the UI. | `visibility` | optional | `PUBLIC` | *Available since version 1.2* Marks an operation's visibility to either `PUBLIC` (anyone can see and use it) or `PRIVATE` (accessible only for the current module and cannot be seen externally), for example: [source,xml,linenums] ---- ---- | `doc:description` | optional | NA | Documentation for the ``. |=== .Attributes of [%header,cols="20,20,30,70a"] |=== |Name | Use | Default Value | Description | `type` | optional | | The data type of the output payload. Note that you can set it to `void` by removing the element. This prevents the `` from modifying the Mule event even if its behavior involves modifying the payload. |=== Attribute type definitions are supported by `` elements when you use the `` element. .Attributes of [%header,cols="20,20,30,70a"] |=== |Name | Use | Default Value | Description | `type` | optional | | The data type of the output attribute. Note that you can set it to `void` by removing the element. This prevents the `` from modifying the Mule event even if its behavior involves modifying the payload. |=== Both outputs (`` and ``) become part of the `MuleMessage` that is created when the control returns to the invoker. .Attributes of ** [%header,cols="20,20,30,70a"] |=== |Name | Use | Default Value | Description | `type` | required | | The type of error code to throw (or remap) in the ``. More info about xref:mule-runtime::mule-error-concept.adoc[Mule Error concept]. |=== === Properties A `` is for a field defined by an end user of the XML SDK component. It serves as a global configuration for the entire Mule project in which it is used. Properties are similar to the parameters exposed by operations, but they act at a level that affects all instances of the XML SDK component in the project, instead of a specific operation. Like parameters in operations, properties are usually simple types that have default values. [TIP] To avoid confusing end users of the XML SDK module, only expose the properties that they might need to edit. For example, do not expose internal values that they cannot or should not change. The following XML SDK module sends requests to https://developer.github.com/v3/users/#get-the-authenticated-user[GitHub API V3] to retrieve an authenticated user: //// TODO: VERIFY THAT THIS WORKS TODO: VERIFY THAT httpn is correct and not http //// [source,xml,linenums] ---- ---- The example references a `` that is defined in the module: * In a global element as the value for a `request-config`. * In an operation as the value to a `config-ref` attribute in an `http-request`. The following Mule app uses XML SDK module. Note that the `github` prefix (for example, `github:get-user`) is derived from the `name` of the module. [source,xml,linenums] ---- ---- Every execution of the `"test-github-flow"` returns the GitHub information of the authenticated user: [source,json,linenums] ---- { "login": "fernandezlautaro", "id": 4719511, "avatar_url": "https://avatars1.githubusercontent.com/u/4719511?v=3", "gravatar_id": "", "url": "https://api.github.com/users/fernandezlautaro", ... } ---- Note that incorrect credentials return this error response from GitHub: [source,json,linenums] ---- { "message": "Requires authentication", "documentation_url": "https://developer.github.com/v3" } ---- . Attributes [%header,cols="20,20,30,70a"] |=== |Name | Use | Default Value | Description | `name` | required | NA | Name of the ``. | `defaultValue` | optional | NA | The `` uses the default value if you do not provide another value. | `use` | required | `AUTO` | Possible values: * `REQUIRED`: Property must be present. It cannot be REQUIRED if the parameter has a `defaultValue`. * `OPTIONAL`: Property is not required. * `AUTO`: Defaults at runtime to `REQUIRED` if `defaultValue` is absent. Otherwise, it is marked as `OPTIONAL`. | `type` | required | NA | Defines the data type of the ``. You can use any primitive type such as `string`, `boolean`, `datetime`, `date`, `number`, `time`, or it can also rely on any type defined in the <>. | `password` | optional | `false` | Hides the value of the property value in the UI when typing it (using `\****`). | `summary` | optional | NA | Adds a small tooltip to the ``. | `example` | `optional` | NA | Adds a short example of the data type for this property. | `displayName` | optional | NA | Provides a UI label. When there is no `displayName`, the default value is a hyphenated version of the `name` attribute. | `order` | optional | NA | Defines an order in which to render each element in the UI. | `tab` | optional | NA | Defines the group (or tab) to which the `` must belong in the UI. | `doc:description` | optional | NA | Documentation for the ``. |=== [NOTE] Extensions made with XML SDK do not support implicit configurations, which means even though all properties defined in the extension are optional, all operations must have a configuration. You can create a configuration without specifying the values of its parameters so you can use the default values. === Module The `` element is the root of an XML SDK module. It contains all properties and operations that belong to the module. . Attributes [%header,cols="20,20,30,70a"] |=== |Name | Use | Default Value | Description | `name` | required | NA | Name of the ``. | `vendor` | optional | `"MuleSoft"` | Vendor of the XML SDK module. | `prefix` | optional | NA | The prefix of the module used when generating schemas. If empty, the module uses a hyphenated version of the `name` attribute. Refer to <>. | `namespace` | optional | NA | Namespace to use for the module during schema generation. Otherwise, the default is `+http://www.mulesoft.org/schema/mule/+` where `` is the `prefix` attribute value. | `doc:description` | optional | NA | Documentation for the ``. |=== You import an XML SDK schema into a Mule app by using the `namespace` attribute. The XML schemas are generated dynamically. The next table shows how `namespace`, `prefix`, and `name` attributes work together. . provides `name`, `prefix`, and `namespace` |=== | Provided Values | Generated Values | `name="hello with spaces"` | `name="hello with spaces"` | `prefix="hello-prefix"` | `prefix="hello-prefix"` | `namespace="http://www.mulesoft.org/schema/a/different/path/mule/hello"` | `namespace="http://www.mulesoft.org/schema/a/different/path/mule/hello"` |=== The generated schema location: `+http://www.mulesoft.org/schema/a/different/path/mule/hello/current/mule-hello-prefix.xsd+` . provides `name` and `prefix` |=== |Provided Values | Generated Values | `name="hello with spaces"` | `name="hello with spaces"` | `prefix="hello-prefix"` | `prefix="hello-prefix"` | NA | `namespace=http://www.mulesoft.org/schema/mule/hello-prefix` |=== Generated schema location: `+http://www.mulesoft.org/schema/mule/hello-prefix/current/mule-hello-prefix.xsd+` . provides just `name` |=== |provided values | generated values | `name="hello with spaces"` | `name="hello with spaces"` | NA | `prefix="hello-with-spaces"` | NA | `namespace=http://www.mulesoft.org/schema/mule/hello-with-spaces` |=== Generated schema location is `+http://www.mulesoft.org/schema/mule/hello-with-spaces/current/mule-hello-with-spaces.xsd+` [[prefix-attribute]] === Prefix Attribute The `prefix` attribute is the prefix of the module used when generating schemas. If empty, the module uses a hyphenated version of the XML SDK `name` attribute. The value of the `prefix` attribute correlates with the name of the folder containing the resource files. Thus, setting or not setting this value affects the name of the resource folder. When setting a prefix with a custom name, you must rename the resource folder to match the custom prefix name. The following module only has a `name` attribute `name="hello with spaces"`. This means that its `prefix` is dynamically generated as `hello-with-spaces`, and its `namespace` is dynamically generated as `+http://www.mulesoft.org/schema/mule/hello-with-spaces/current/mule-hello-with-spaces.xsd+`. It also means that the Mule app must have a schema location (`schemaLocation`) that points to a reference that matches that value. [source,xml,linenums] ---- ---- This `hello with spaces` module above can be used in a Mule app, for example: [source,xml,linenums] ---- ---- == Create and test an XML SDK Project To create an XML SDK module: . Add the MuleSoft repository to your Maven (`mvn`) settings file: + [source,text,linenums] ---- Mule true mulesoft-releases MuleSoft Repository http://repository.mulesoft.org/releases/ default ---- . Use Maven (`mvn`) from to execute the following command: + [source,text,linenums] ---- mvn archetype:generate \ -DarchetypeGroupId=org.mule.extensions \ -DarchetypeArtifactId=mule-extensions-xml-archetype \ -DarchetypeVersion=1.2.0 \ -DgroupId=org.mule.extension \ -DartifactId=hello-mule-extension \ -DmuleConnectorName=Hello ---- + [TIP] Since the connector name above is `Hello`, the namespace for the module will be automatically set to `module-hello`, as configured in the `prefix` attribute. . When prompted to indicate whether the values are correct, press `enter` to continue. + The Maven archetype creates a stub project with a minimal amount of code for the XML SDK module and a functional test to run it. The structure of that project looks something like this: + [source,text,linenums] ---- ➜ hello-mule-extension tree . . ├── pom.xml └── src ├── main │ └── resources │ └── org │ └── mule │ └── yourdomain │ └── module-Hello.xml // <1> └── test └── munit └── assertion-munit-test.xml // <2> 8 directories, 3 files ---- + (1) `hello-mule-extension/src/main/resources/org/mule/yourdomain/module-Hello.xml`: Defines the XML SDK root element. + (2) `hello-mule-extension/src/test/munit/assertion-munit-test.xml`: An assertion operation that calls the XML SDK operation. + . Run `mvn clean install` in the `/hello-mule-extension` to create the plugin for the `Hello XML SDK` module. + This command installs a parent project as well as its child projects. It also runs the suite through MUnit for the operation defined in the module. + [source,text,linenums] ---- ➜ hello-mule-extension mvn clean install ... .. . ================================================================================== Number of tests run: 2 - Failed: 0 - Errors: 0 - Skipped: 0 - Time elapsed: 2246ms ================================================================================== [INFO] ==================================================================================== [INFO] MUnit Run Summary - Product: MULE, Version: 4.1.1 [INFO] ==================================================================================== [INFO] >> assertion-munit-test.xml test result: Tests: 2, Errors: 0, Failures: 0, Skipped: 0 [INFO] [INFO] ==================================================================================== [INFO] > Tests: 2 [INFO] > Errors: 0 [INFO] > Failures: 0 [INFO] > Skipped: 0 [INFO] ==================================================================================== .... ... .. [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 39.166 s [INFO] Finished at: 2017-06-14T22:07:42-03:00 [INFO] Final Memory: 61M/928M [INFO] ------------------------------------------------------------------------ ➜ hello-smart-connector ---- + (3) When you want to add this connector to a project from your local Maven repository for testing, add the following dependency: ---- org.mule.extension hello-mule-extension 1.0.0-SNAPSHOT mule-plugin ---- + You can now use this connector from your Studio palette. + [[customicon]] include::partial$set-custom-icon.adoc[] == Consuming a Mule Plugin from an XML SDK Module To consume a Mule plugin from within an XML SDK module: . Add the dependency into the POM file for the XML SDK module. + For example, for an XML SDK module to use the HTTP connector and the OAuth module, the POM needs to include the following dependencies: + [source,xml,linenums] ---- org.mule.connectors mule-http-connector 1.2.1 mule-plugin compile org.mule.modules mule-oauth-module 1.1.2 mule-plugin compile ---- + . Add the schema location to the `` root element, for example: + [source,xml,linenums] ---- ... ---- == Reuse Operations In some cases, operations have repeated message processors, on which we can rely if they are encapsulated in a new operation and called from other places. Each `` defined in a `` can be reused in the _same_ `` if the operation does not have cyclic dependencies. For example, assume that a `` validates input parameters before performing inserts and updates. Notice that validations in the next example are repeated in the operations `validate-and-insert` and `validate-and-update`. [source,xml,linenums] ---- INSERT INTO PLANET(NAME) VALUES (:name) #[{ 'name' : vars.name }] update PLANET set NAME= :newName where NAME=':originalName' #[{'originalName' : vars.originalName, 'newName' : vars.newName}] ---- To simplify this process in the previous example, you can add a `validate` operation that you call from the other operations, for example: [source,xml,linenums] ---- ---- To consume the other operations from within a ``: . Add an XML namespace `xmlns:tns` attribute and a new value to `schemaLocation` to the ``. + Note that the value must map the target namespace of the current module. + . Call the operations by using the `tns` prefix followed by the name of the operation.The complete module looks something like this: + [source,xml,linenums] ---- INSERT INTO PLANET(NAME) VALUES (:name) #[{ 'name' : vars.name }] update PLANET set NAME= :newName where NAME=':originalName' #[{'originalName' : vars.originalName, 'newName' : vars.newName}] ---- Note that the `config-ref` is not included because this is a reference to the _same_ module, which implies all global instances are shared among operations. == Reuse Operations Within Operations To reuse an operation within another operation with a `use=CONTENT` xref:content-parameters.adoc[content parameter], reference the `use=CONTENT` parameter in the inner tag name. Suppose there is a `shared-operation` operation that defines its `requiredParameter` parameter with `use=CONTENT`. Another operation, `sample-operation`, reuses `shared-operation` within its own definition, for example: [source,xml,linenums] ---- #[vars.required-Parameter] ---- [NOTE] Notice that the parameter, *requiredParameter*, uses the camel case naming convention, but the reference, *vars.required-Parameter*, uses the kebab case naming convention. When you name a parameter or an operation, use the kebab case naming convention to ensure consistency within your project. Refer to <>. The `requiredParameter` value must be referenced as an inner tag of `sample-operation`. Otherwise, the project throws a build error, such as, `Attribute 'required-parameter' is not allowed to appear in element 'tns:shared-operation'.` The XML definition of the connector generates parameters set with `use=CONTENT` as inner tags. Refer to xref:content-parameters.adoc#content-param[File Connector], in which the parameter named `content` is set with `use=CONTENT` as the inner tag ``. == Providing a Test Connection At design time, it is helpful to provide feedback when the attributes of a global element are fed with wrong values, such as wrong username or password, bad URLs, and so on. To provide such feedback, your module needs to incorporate a global element that supports connection testing. For example, the XML SDK module `` might use the connection testing functionality from the File connector by incorporating the `file:connection` element into the module. By default, the module picks up and supports the connection testing feature from the File configuration. [source,xml,linenums] ---- ---- From the UI, connection testing is delegated to the global element encapsulated by `fileConfig`. If a module contains two or more global elements that provide a test connection, an error occurs when you build the module unless you mark the global element that you want to use with the `xmlns:connection="true"` attribute, for example: [source,xml,linenums] ---- ---- [NOTE] Marking multiple global elements with `xmlns:connection="true"` makes the compilation fail, as there can be only one. == Handling Errors In some cases, operations within the `` throw error codes that should not be propagated as-is. In this case, you need to remap the codes to something more meaningful to the end user. In other cases, the issues might pertain to conditions within the ``. The XML SDK relies on xref:mule-runtime::mule-error-concept.adoc#error-mappings[error mappings] for the former. For the latter, the xref:mule-runtime::raise-error-component-reference.adoc[raise error component] is used. This example performs error mapping in an operation that divides two numbers: [source,xml,linenums] ---- ... ---- If the divisor `numberB` is zero, the `div` operation results in the `MULE:EXPRESSION` runtime error, which does not describe the error specifically enough. To create a more specific error, you can use error mapping to make the `div` operation produce the `MATH-XML-SDK:DIVISION_BY_ZERO` error. You must include the namespace in the custom error to avoid unexpected behavior. For example: [source,xml,linenums] ---- ... ---- You can produce the same error by executing a validation before the evaluation of the expression `#[vars.numberA / vars.numberB]`. If the expression fails, the `MATH-XML-SDK:DIVISION_BY_ZERO` error results, for example: [source,xml,linenums] ---- ... ---- [[xml_sdk_catalog]] == XML SDK Catalog The standard data types for `` and `` are primitive types: `string`, `boolean`, `number`, `date`, `datetime`, `localdatetime`, `time`, `localtime`, `timezone`, `binary`, `any`, `regex`. To define types that with more complex structures than the primitive types, you can create a catalog of data types that you inject into the module. This example creates a catalog file (`hello-smart-connector/smart-connector/src/main/resources/module-Hello-catalog.xml`) with the following content: [source,xml,linenums] ---- ---- The catalog file references XSD and JSON schema files: * `person-schema.xsd`, which contains the following content: + [source,xml,linenums] ---- ---- + * `person-schema.json`, which contains the following content: + [source,json,linenums] ---- { "type": "object", "properties": { "age": { "type": "integer" }, "name": { "type": "string" }, "lastname": { "type": "string" } }, "additionalProperties": false } ---- So, the structure of the `tree hello-smart-connector/smart-connector` folder looks like this: [source,text,linenums] ---- ➜ ~ tree hello-smart-connector/smart-connector hello-smart-connector/smart-connector ├── pom.xml └── src └── main └── resources ├── module-Hello-catalog.xml ├── module-Hello.xml ├── person-schema.json └── person-schema.xsd ---- Once the schemas are ready, you use types they define by referencing the associated catalogs (`PersonXsdType` and `PersonJsonType`), for example: [[example]] [source,xml,linenums] ---- ... ---- Notice that the value of the `type` attribute for the JSON schema is the name of the catalog that contains that schema (`PersonJsonType`). However, for the XML schema, the value of the `type` attribute appends two colons `::` and the qname (qualified name) reference to the `Person` element: `PersonXsdType::{http://uri}Person`. To perform the DataWeave transformation from JSON to XML (shown within ``), it is necessary to add the following dependency to the POM file so that the module can find the required schema (`mule-ee.xsd`): [source,xml,linenums] ---- com.mulesoft.mule.runtime.modules mule-module-spring-config-ee ${mule.version} provided ---- To use the operations from the <> above in a Mule app, it is necessary to feed values to them, for example: [source,xml,linenums] ---- ---- When parameterizing values that are not primitive types, the defined `` can declare them as `role="CONTENT"` so that it is not mandatory to use an additional processor in the `` to call the operation. The `person-xml-to-json` operation in this example adds this attribute to the `content` parameter: [[example2]] [source,xml,linenums] ---- ... ... ---- To use the operations from the <> above in a Mule app, it is necessary to feed values to them, for example: [source,xml,linenums] ---- .. ---- [[xml-sdk-tls]] == TLS Support Starting with Mule 4.6, XML SDK supports Transport Layer Security (TLS). Use TLS to enhance security for your app. XML SDK connectors can support the `` parameter in their configuration parameters. === Parameter Declaration Use the `xmlns:tlsEnabled=true` annotation to specify that the component supports TLS. The annotated element does not necessarily have to be a top-level element. In the following example, the annotated element is `` which is a child of the `` top-level element: [source,xml,linenums] ---- ---- You can specify the `` parameter in only one component. Using it on more than one component results in an error. XML SDK adds a `` parameter in the configuration of the generated extension. This parameter is optional unless the `` parameter in the target element is required and doesn’t have a default value. In the generated extension, the supplied `` parameter is mapped to the config element with this annotation. You can declare the `` parameter inline or by-reference: * Inline declaration + [source,xml,linenums] ---- ---- * By-reference declaration + [source,xml,linenums] ---- ---- === Parameter Default Value The target element can already provide a value for the `` parameter, for example: [source,xml,linenums] ---- a ---- In this case, the value that comes from the module definition is used as the default. The synthetic parameter is also added to the module config, which, if provided, is used as an override. For both inline and by-reference declarations, providing a default value at the target element makes the synthetic parameter optional even if the parameter at the target element is required. == Working Examples of XML SDK Modules https://github.com/mulesoft-labs/smart-connectors-integration-tests contains the following directories: * `apps-using-smart-connectors`: Mule apps that use XML SDK modules * `smart-connectors`: XML SDK modules that incorporate DataWeave, HTTP connector, File connector, Validation module, and so on. The following subsections describe some of these examples. [[module-using-core]] === Example: Using Core Components This example incorporates core components, such as Set Payload (`mule:set-payload`). GitHub Location: https://github.com/mulesoft-labs/smart-connectors-integration-tests/tree/master/smart-connectors/smart-connector-using-core[smart-connectors/smart-connector-using-core] [source,xml,linenums] ---- ---- === Example: Using JSON Custom Types This example incorporates JSON types. GitHub Location: https://github.com/mulesoft-labs/smart-connectors-integration-tests/tree/master/smart-connectors/smart-connector-using-custom-types-json[smart-connectors/smart-connector-using-custom-types-json] [source,xml,linenums] ---- ---- .Catalog [source,xml,linenums] ---- ---- .Schema [source,json,linenums] ---- { "type": "object", "properties": { "number": { "type": "number" }, "street_name": { "type": "string" }, "street_type": { "type": "string", "enum": [ "Street", "Avenue", "Boulevard" ] } }, "additionalProperties": false } ---- === Example: Using Custom XML Types This example incorporates custom XML types. GitHub Location: https://github.com/mulesoft-labs/smart-connectors-integration-tests/tree/master/smart-connectors/smart-connector-using-custom-types-xsd[smart-connectors/smart-connector-using-custom-types-xsd] [source,xml,linenums] ---- ---- .Catalog [source,xml,linenums] ---- ---- .Schema 1 [source,xml,linenums] ---- A user with all the information ---- === Example: Exporting Resources This example explains how to add a resource to your project so that it is exported and packaged with your connector. GitHub Location: https://github.com/mulesoft-labs/smart-connectors-integration-tests/tree/master/smart-connectors/smart-connector-exporting-resources[smart-connectors/smart-connector-exporting-resources] As the objective is to export a resource and make it available in the main mule app, the module file `module-exporting-resources.xml` does not contain any functionality. [[module-exporting-resources]] .module-exporting-resources.xml [source,xml,linenums] ---- ---- The following resource file is exported: .myMappings.dwl [source,text,linenums] ---- %dw 2.0 /****************************************************************************************************************************** NOTICE: This file, `dwModule.dwl`, must be referenced in the META-INF/mule-artifact/mule-artifact.json file to properly export the resource so that the the functions being consumed (`five()`, `echo(String)`, `toUpper(Person)`, `toUpper(Array): Array = persons map toUpper($) ---- The resource file *must* be placed inside a new folder named after the module's name (which was defined in the <>). In this example, the module is named `module-exporting-resources`, so the folder must be named `module_exporting_resources`. Note that hyphens are replaced with underscores. All files contained in this new folder or its subfolders are automatically exported by the XML SDK. In the example, the folder structure looks like this: [source,text,linenums] ---- smart-connector-exporting-resources ├── pom.xml └── src └── main └── resources ├── module-exporting-resources.xml └── module_exporting_resources └── weirdFolder └── myMappings.dwl ---- Finally, the exported file can be used in a Mule flow. This first example illustrates how to use the dataweave functions defined in the exported file: [source,xml,linenums] ---- ---- This second example shows how to access the file through its location to be used by, for instance, the https://docs.mulesoft.com/mule-runtime/4.3/parse-template-reference[Parse Template] component. [source,xml,linenums] ---- ---- === Example: Using DataWeave This example incorporates DataWeave by using the Transform (`ee:transform`) component. GitHub Location: https://github.com/mulesoft-labs/smart-connectors-integration-tests/tree/master/smart-connectors/smart-connector-using-dw[smart-connectors/smart-connector-using-dw] [source,xml,linenums] ---- ---- === Example: Using the File Connector Location `https://github.com/mulesoft-labs/smart-connectors-integration-tests/tree/master/smart-connectors/smart-connector-using-file[smart-connectors/smart-connector-using-file]`: depends on File Connector, e.g.: `file:list` [source,xml,linenums] ---- ---- === Using HTTP Connector This example incorporates the HTTP connector, using an HTTP Request (`http:requester`). GitHub Location: https://github.com/mulesoft-labs/smart-connectors-integration-tests/tree/master/smart-connectors/smart-connector-using-http[smart-connectors/smart-connector-using-http] [source,xml,linenums] ---- ---- === Example: Using Another XML SDK This example shows one XML SDK module (`module-using-smart-connector`) using the XML SDK module `module-using-core` (described in <>). GitHub Location: https://github.com/mulesoft-labs/smart-connectors-integration-tests/tree/master/smart-connectors/smart-connector-using-smart-connector[smart-connectors/smart-connector-using-smart-connector] [source,xml,linenums] ---- ---- === Using the Validation Module This example uses the Validation module, specifically `validation:is-email`. GitHub Location: https://github.com/mulesoft-labs/smart-connectors-integration-tests/tree/master/smart-connectors/smart-connector-using-validation[smart-connectors/smart-connector-using-validation] [source,xml,linenums] ---- ---- [[xml-sdk-limitations]] == XML SDK Limitations The SDK currently has the following limitations: * XML SDK only provides outbound operations, not sources (such as a ``) or routers. * Operations do not support recursive calls. * Operations cannot have parameters called `name` or `config-ref` as those are reserved keywords. * Use the kebab case naming convention to name parameters and operations in any XML SDK project to prevent errors while generating XML tags, as the name values are converted to contain hyphens between words.