Edit eMagiz Mendix Connector configuration
XML schema
XML schema used by the request handler to validate all incoming SOAP web service requests against. Invalid SOAP requests will result in a SOAP Fault response containing the validation errors.
This XML schema is also used to automatically create the WSDL from, placing the following requirements on the contents:
- the XML schema must specify a "targetNamespace"
- for each web service operation (i.e. for every entry connector flow) there must be a request & response pair specified
- the name of a request element must be the operation name appended with the suffix "Request"
- the name of a response element must be the operation name appended with the suffix "Response"
- the response elements of all asynchronous entry connector flows must be empty
Required
Username
Username for accessing the web services hosted by this request handler (HTTP basic access authentication).
When deploying your Mendix app in the Mendix cloud it's not possible to prevent public access to this request handler, so using (random) credentials that are impossible to guess is strongly recommended.
Using a property placeholder is recommended, as the credentials usually differ between test, acceptation and production environments.
Required
Password
Password for accessing the web services hosted by this request handler (HTTP basic access authentication).
When deploying your Mendix app in the Mendix cloud it's not possible to prevent public access to this request handler, so using (random) credentials that are impossible to guess is strongly recommended.
Using a property placeholder is recommended, as the credentials usually differ between test, acceptation and production environments.
Required
Failover
Determines whether or not the connection to the JMS server should support failover.
Enabling failover for the connection is only useful when there are at least two JMS servers: one live server and one backup server.
Cluster
Determines whether or not the connection to the JMS server should support clusters, i.e. the JMS client may connect to any available JMS server in the cluster.
Enabling cluster connections is only useful when there is a cluster of at least two JMS servers available that this connector could create connections with.
Username
Username for creating connections with the JMS server(s).
Using a property placeholder is recommended, as the credentials usually differ between test, acceptation and production environments.
Optional ; security can be disabled on the JMS server, but this is not recommended.
Password
Password for creating connections with the JMS server(s).
Using a property placeholder is recommended, as the credentials usually differ between test, acceptation and production environments.
Optional ; security can be disabled on the JMS server, but this is not recommended.
Sync receive timeout
Timeout for the JMS message consumer to receive the JMS reply message in case of synchronous (request/response) message flows.
Default is 20000
milliseconds (twenty seconds).
Optional
Queue
Name of the JMS queue this exit connector will consume messages from.
Required
XML to domain mapping
Name of the Mendix XML-to-domain mapping to execute on the message payload (must include the module name).
Example: MyModule.MyXmlToDomainMapping
Required
Transaction
Whether to execute the Mendix XML-to-domain mapping in a (Mendix) transaction or not.
Not using a transaction might have a positive impact on the performance, but could lead to an "incorrect" database state (without a transaction, no rollback is performed when errors occur during the XML import).
Default is false.
Logout
The Mendix XML-to-domain mapping is executed in a newly created system context each time a message arrives. Due to changes in the garbage collection from Mendix 4.8.0 onwards, you might get out-of-memory exceptions when working with high volumes of messages. In this case "logging out" the system session solves this because it will immediately trigger the garbage collection. In Mendix 5 however, this is no longer an option.
To conclude: when running in Mendix 4.7.2 or lower, or any Mendix 5 version, you'll want to disable this option. In any Mendix 4 version from 4.8.0 onwards, you might need to enable it.
Default is false.
Queue
Name of the JMS queue this exit connector will consume messages from.
Required
Queue
Name of the JMS queue this entry connector will send its messages to.
Required
Request qualified name
Fully qualified name of the web service request XML root element. The definition of this XML element must be specified in the XML schema of the request handler.
Usually consists of the web service namespace, the web service operation, and the suffix 'Request'. For example: {http://www.example.com/}SendMessageRequest
Required
Queue
Name of the JMS queue this entry connector will send its request messages to.
Required
Response queue
Name of the JMS queue this entry connector will consume the response messages from.
Required
Request qualified name
Fully qualified name of the web service request XML root element. The definition of this XML element must be specified in the XML schema of the request handler.
Usually consists of the web service namespace, the web service operation, and the suffix 'Request'. For example: {http://www.example.com/}SendMessageRequest
Required
Queue
Name of the JMS queue this exit connector will consume request messages from.
Required
Response queue
Name of the JMS queue this exit connector will send its response messages to.
Required
The name of the JMS queue (hosted by the JMS server of this message bus) where this connector will send any error messages to.
Error messages are generated when an exit connector flow cannot successfully deliver a message to the Mendix app and that flow's error handling is set to error message (the default).
The name of the header to be added to every outgoing message, to identify which tenant sent it.
Default: busName_sourceTenant
Required
The name of the tenant to be added to every outgoing message, to identify which tenant sent it.
Default (property): ${systemName.tenant.name}
Required
Determines whether or not the connection to the AMQP server should support failover.
Enabling failover for the connection is only useful when there are at least two JMS servers: one live server and one backup server.
Determines whether or not the connection to the AMQP server should support clusters, i.e. the JMS client may connect to any available JMS server in the cluster.
Enabling cluster connections is only useful when there is a cluster of at least two JMS servers available that this connector could create connections with.
Username value used to authenticate the connection.
Required
The password value used to authenticate the connection.
Required
Whether to verify that the hostname being connected to matches with the provided server certificate.
Default is true.
Enable the WebSocket protocol.
Default is true.
This is the path to the SSL key store on the client which holds the client certificates. Only used when SSL is enabled.
Default is to read from the system property "javax.net.ssl.keyStore".
This is the password for the SSL key store on the client which holds the client certificates. Only used when SSL is enabled.
Default is to read from the system property "javax.net.ssl.keyStorePassword"
This is the path to the trusted client certificate store on the server. Only used when SSL is enabled.
Default is to read from the system property "javax.net.ssl.trustStore".
This is the password to the trusted client certificate store on the server. Only used when SSL is enabled.
Default is to read from the system property "javax.net.ssl.trustStorePassword"
Enable SSL to secure connections.
Default is false.
Error queue
The name of the JMS queue (hosted by the JMS server of this message bus) where this connector will send any error messages to.
Error messages are generated when an exit connector flow cannot successfully deliver a message to the Mendix app and that flow's error handling is set to error message (the default).
Required
The name of the header to be added to every outgoing message, to identify which tenant sent it.
Default: busName_sourceTenant
Required
The name of the tenant to be added to every outgoing message, to identify which tenant sent it.
Default (property): ${systemName.tenant.name}
Required
Webservice URL
URL of the Mendix web service where this exit connector should deliver its messages to.
Note that when running in the Mendix cloud, the only option is to use the public URL. For example: https://myapp.mendixcloud.com/ws/MyService
Using a property placeholder is recommended, as the URL usually differs between test, acceptation and production environments.
Required
Mx username
Username for accessing the web service hosted by the Mendix app.
When deploying your Mendix app in the Mendix cloud it's not possible to prevent public access to the web services, so using (random) credentials that are impossible to guess is strongly recommended.
Using a property placeholder is recommended, as the credentials usually differ between test, acceptation and production environments.
Optional ; security can be disabled on Mendix web services, but this is not recommended when the app is publicly accessible.
Mx password
Password for accessing the web service hosted by the Mendix app.
When deploying your Mendix app in the Mendix cloud it's not possible to prevent public access to the web services, so using (random) credentials that are impossible to guess is strongly recommended.
Using a property placeholder is recommended, as the credentials usually differ between test, acceptation and production environments.
Optional ; security can be disabled on Mendix web services, but this is not recommended when the app is publicly accessible.
Connect timeout
Sets a specified timeout value, in milliseconds, to be used when opening a communications link to the Mendix web service. If the timeout expires before the connection can be established, a java.net.SocketTimeoutException
is raised. A timeout of zero is interpreted as an infinite timeout.
Optional ; if not specified the Java default of 0
(infinite) is used.
Read timeout
Sets the read timeout to a specified timeout, in milliseconds. A non-zero value specifies the timeout when reading (response) data after successfully connecting to the Mendix web service. If the timeout expires before there is data available for read, a java.net.SocketTimeoutException
is raised. A timeout of zero is interpreted as an infinite timeout.
Note that this is a client-side setting: after a timeout the eMagiz Mendix Connector will execute the configured error handling, but Mendix might actually still be busy processing the request. This can lead to data duplication or even thread starvation in Mendix, so consider each use case carefully.
Optional ; if not specified the Java default of 0
(infinite) is used.
Webservice URL
URL of the Mendix web service where this exit connector should deliver its messages to.
Note that when running in the Mendix cloud, the only option is to use the public URL. For example: https://myapp.mendixcloud.com/ws/MyService
Using a property placeholder is recommended, as the URL usually differs between test, acceptation and production environments.
Required
Mx username
Username for accessing the web service hosted by the Mendix app.
When deploying your Mendix app in the Mendix cloud it's not possible to prevent public access to the web services, so using (random) credentials that are impossible to guess is strongly recommended.
Using a property placeholder is recommended, as the credentials usually differ between test, acceptation and production environments.
Optional ; security can be disabled on Mendix web services, but this is not recommended when the app is publicly accessible.
Mx password
Password for accessing the web service hosted by the Mendix app.
When deploying your Mendix app in the Mendix cloud it's not possible to prevent public access to the web services, so using (random) credentials that are impossible to guess is strongly recommended.
Using a property placeholder is recommended, as the credentials usually differ between test, acceptation and production environments.
Optional ; security can be disabled on Mendix web services, but this is not recommended when the app is publicly accessible.
Connect timeout
Sets a specified timeout value, in milliseconds, to be used when opening a communications link to the Mendix web service. If the timeout expires before the connection can be established, a java.net.SocketTimeoutException
is raised. A timeout of zero is interpreted as an infinite timeout.
Optional ; if not specified the Java default of 0
(infinite) is used.
Read timeout
Sets the read timeout to a specified timeout, in milliseconds. A non-zero value specifies the timeout when reading (response) data after successfully connecting to the Mendix web service. If the timeout expires before there is data available for read, a java.net.SocketTimeoutException
is raised. A timeout of zero is interpreted as an infinite timeout.
Note that this is a client-side setting: after a timeout the eMagiz Mendix Connector will execute the configured error handling, but Mendix might actually still be busy processing the request. This can lead to data duplication or even thread starvation in Mendix, so consider each use case carefully.
Optional ; if not specified the Java default of 0
(infinite) is used.
XML schema
XML schema to validate messages against after consuming them from the JMS queue but before delivering them to the Mendix app. If validation fails the error handling of this exit connector is triggered.
Optional ; if not specified, no validation is performed on the messages.
Error handling
How this exit connector should handle errors when delivering a message to the Mendix app fails:
Error message Sends an error message (containing the cause and the message content) to the error queue on the JMS server and commits the JMS transaction.
Ignore Silently ignores the error and commits the JMS transaction. Note that in this case the message content is lost.
Log Sends the error to the Mendix log and commits the JMS transaction. Note that in this case the message content is lost.
Rollback Rolls back the JMS transaction. What happens next with the message depends on the redelivery settings of the JMS queue this exit connector consumed the message from.
Default is error message.
Maximum attempts
The number of attempts before a retry becomes impossible. The number of attempts includes the initial try.
Default is 1
: only try once.
Back off period
The back off period in milliseconds. This is a fixed period of time before the next attempt is made.
If the maximum number of attmpts is set to 1 (default), this setting has no effect.
Default is 1000
ms (1 second).
Concurrent consumers
Configure the concurrency behaviour of this exit connector, by specifing the initial number of concurrent consumers to create, the maximum number of concurrent consumers that is allowed to be created and the idle consumer limit:
Initial concurrent consumers Specifying a higher value for this setting will increase the standard level of scheduled concurrent consumers at runtime: this is effectively the minimum number of concurrent consumers which will be scheduled at any given time. This is a static setting; for dynamic scaling, consider specifying the maximum concurrent consumers setting instead.
Maximum concurrent consumers If this setting is higher than initial concurrent consumers, the listener container will dynamically schedule new consumers at runtime, provided that enough incoming messages are encountered. Once the load goes down again, the number of consumers will be reduced to the standard level again. Raising the number of concurrent consumers is recommendable in order to scale the consumption of messages coming in from a queue. However, note that any ordering guarantees are lost once multiple consumers are registered. In general, stick with 1 consumer for low-volume queues.
Idle consumer limit
Specifies the limit for the number of consumers that are allowed to be idle at any given time. This limit is used to determine if a new invoker should be created. Increasing the limit causes invokers to be created more aggressively. This can be useful to ramp up the number of invokers faster. The default is 1
, only scheduling a new invoker (which is likely to be idle initially) if none of the existing invokers is currently idle.
Default for all three settings is 1
.
Optional
XML schema
XML schema to validate messages against after consuming them from the JMS queue but before delivering them to the Mendix app. If validation fails the error handling of this exit connector is triggered.
Optional ; if not specified, no validation is performed on the messages.
Error handling
How this exit connector should handle errors when delivering a message to the Mendix app fails:
Error message Sends an error message (containing the cause and the message content) to the error queue on the JMS server and commits the JMS transaction.
Ignore Silently ignores the error and commits the JMS transaction. Note that in this case the message content is lost.
Log Sends the error to the Mendix log and commits the JMS transaction. Note that in this case the message content is lost.
Rollback Rolls back the JMS transaction. What happens next with the message depends on the redelivery settings of the JMS queue this exit connector consumed the message from.
Default is error message.
Maximum attempts
The number of attempts before a retry becomes impossible. The number of attempts includes the initial try.
Default is 1
: only try once.
Back off period
The back off period in milliseconds. This is a fixed period of time before the next attempt is made.
If the maximum number of attmpts is set to 1 (default), this setting has no effect.
Default is 1000
ms (1 second).
Concurrent consumers
Configure the concurrency behaviour of this exit connector, by specifing the initial number of concurrent consumers to create, the maximum number of concurrent consumers that is allowed to be created and the idle consumer limit:
Initial concurrent consumers Specifying a higher value for this setting will increase the standard level of scheduled concurrent consumers at runtime: this is effectively the minimum number of concurrent consumers which will be scheduled at any given time. This is a static setting; for dynamic scaling, consider specifying the maximum concurrent consumers setting instead.
Maximum concurrent consumers If this setting is higher than initial concurrent consumers, the listener container will dynamically schedule new consumers at runtime, provided that enough incoming messages are encountered. Once the load goes down again, the number of consumers will be reduced to the standard level again. Raising the number of concurrent consumers is recommendable in order to scale the consumption of messages coming in from a queue. However, note that any ordering guarantees are lost once multiple consumers are registered. In general, stick with 1 consumer for low-volume queues.
Idle consumer limit
Specifies the limit for the number of consumers that are allowed to be idle at any given time. This limit is used to determine if a new invoker should be created. Increasing the limit causes invokers to be created more aggressively. This can be useful to ramp up the number of invokers faster. The default is 1
, only scheduling a new invoker (which is likely to be idle initially) if none of the existing invokers is currently idle.
Default for all three settings is 1
.
Optional
XML schema
XML schema to validate messages against after consuming them from the JMS queue but before delivering them to the Mendix app. If validation fails the error handling of this exit connector is triggered.
Optional ; if not specified, no validation is performed on the messages.
Error handling
How this exit connector should handle errors when delivering a message to the Mendix app fails:
Error message Sends an error message (containing the cause and the message content) to the error queue on the JMS server and commits the JMS transaction.
Ignore Silently ignores the error and commits the JMS transaction. Note that in this case the message content is lost.
Log Sends the error to the Mendix log and commits the JMS transaction. Note that in this case the message content is lost.
Rollback Rolls back the JMS transaction. What happens next with the message depends on the redelivery settings of the JMS queue this exit connector consumed the message from.
Default is error message.
Maximum attempts
The number of attempts before a retry becomes impossible. The number of attempts includes the initial try.
Default is 1
: only try once.
Back off period
The back off period in milliseconds. This is a fixed period of time before the next attempt is made.
If the maximum number of attmpts is set to 1 (default), this setting has no effect.
Default is 1000
ms (1 second).
Concurrent consumers
Configure the concurrency behaviour of this exit connector, by specifing the initial number of concurrent consumers to create, the maximum number of concurrent consumers that is allowed to be created and the idle consumer limit:
Initial concurrent consumers Specifying a higher value for this setting will increase the standard level of scheduled concurrent consumers at runtime: this is effectively the minimum number of concurrent consumers which will be scheduled at any given time. This is a static setting; for dynamic scaling, consider specifying the maximum concurrent consumers setting instead.
Maximum concurrent consumers If this setting is higher than initial concurrent consumers, the listener container will dynamically schedule new consumers at runtime, provided that enough incoming messages are encountered. Once the load goes down again, the number of consumers will be reduced to the standard level again. Raising the number of concurrent consumers is recommendable in order to scale the consumption of messages coming in from a queue. However, note that any ordering guarantees are lost once multiple consumers are registered. In general, stick with 1 consumer for low-volume queues.
Idle consumer limit
Specifies the limit for the number of consumers that are allowed to be idle at any given time. This limit is used to determine if a new invoker should be created. Increasing the limit causes invokers to be created more aggressively. This can be useful to ramp up the number of invokers faster. The default is 1
, only scheduling a new invoker (which is likely to be idle initially) if none of the existing invokers is currently idle.
Default for all three settings is 1
.
Optional