| Namespace | http://www.mulesoft.org/schema/mule/wd-notification |
|---|---|
| Schema Location | http://www.mulesoft.org/schema/mule/wd-notification/current/mule-wd-notification.xsd (View Schema) |
| Schema Version | 2.0 |
| Minimum Mule Version | 3.4 |
The Notification Web Service provides an operation that informs external systems of business events that occur within Workday. The WSDL for this service provides the structure that needs to be implemented by an external system to receive notifications for their subscribed Workday business events. Subscriptions and Notification details (i.e. Endpoint and security information) are defined within the Workday application.
| Configuration | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Configure an instance of this module
| |||||||||||
| Message Processors | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Receives notification from Workday
| |||||||||||
To use the this module within a flow the namespace to the module must be included. The resulting flow will look similar to the following:
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wd-notification="http://www.mulesoft.org/schema/mule/wd-notification"
xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core
http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/wd-notification
http://www.mulesoft.org/schema/mule/wd-notification/current/mule-wd-notification.xsd">
<!-- here goes your flows and configuration elements -->
</mule>
This connector offers automatic connection management via the use of a connection pool. The pool will act a storage mechanism for all the connections that are in-use by the user of this connector.
Prior to execution of a processor, the connector will attempt to lookup an already established connection and if one doesn't exists it will create one. That lookup mechanism is done in the connection pool via the use of connection variables declared as keys.
The user of the connector can configure the pool by adding a connection-pooling-profile to the connector configuration like this:
<wd-notification:connection-pooling-profile maxActive="10" maxIdle="10"
exhaustedAction="WHEN_EXHAUSTED_GROW" maxWait="120" minEvictionMillis="60000" evictionCheckIntervalMillis="30000"/>
The following is a list of connection attributes, each connection attribute can be configured at the config element level or they can also be added to each processor. If they are used at the processor level they get the benefit of full expression resolution.
| Connection Attributes | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Name | Default Value | Description | Java Type | MIME Type | Encoding | ||||||
| Optional. Specify which configuration to use. | |||||||||||
| Workday user | String | */* | UTF-8 | ||||||||
| Workday password | String | */* | UTF-8 | ||||||||
| Workday endpoint | String | */* | UTF-8 | ||||||||
| Optional. Workday WSDL location | String | */* | UTF-8 | ||||||||
Reconnection Strategies specify how a connector behaves when its connection fails. You can control how Mule attempts to reconnect by specifying a number of criteria:
With a reconnection strategy, you can better control the behavior of a failed connection, by configuring it, for example, to re-attempt the connection only once every 15 minutes, and to give up after 30 attempts. You can also send an automatic notification to your IT administrator whenever this reconnection strategy goes into effect. You can even define a strategy that attempts to reconnect only during business hours. Such a setting can prove useful if your server is frequently shut down for nightly maintenance.
A reconnection strategy that allows the user to configure how many times a reconnection should be attempted and how long to wait between attempts.
<wd-notification:config>
<reconnect count="5" frequency="1000"/>
</wd-notification:config>
| Reconnect Attributes | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Name | Default Value | Description | |||||||||
| Optional. How often (in ms) to reconnect | |||||||||||
| Optional. How many reconnection attempts to make | |||||||||||
For more information about reconnection strategies in Mule, or even how to write your own custom reconnection strategy please check this section.
Receives notification from Workday
INCLUDE_ERROR
| Name | Default Value | Description | Java Type | MIME Type | Encoding | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Optional. Specify which configuration to use. | |||||||||||
| #[payload] | Optional. Request element | NotificationDataRootType | */* | ||||||||
| Connection Parameters This are only required if you didn't specified them at the configuration element. They are also useful for overriding the values of the configurations or even if you need to extract them from the Mule message since they support expression evaluation. | |||||||||||
| Optional. Workday user | String | */* | UTF-8 | ||||||||
| Optional. Workday password | String | */* | UTF-8 | ||||||||
| Optional. Workday endpoint | String | */* | UTF-8 | ||||||||
| https://community.workday.com/custom/developer/API/Notification/v20/Notification.wsdl | Optional. Workday WSDL location | String | */* | UTF-8 | |||||||
| Return Type | Description |
|---|---|
| NotificationDataRootType | notificationData request |
| Payload Class | Description |
|---|---|
| WorkdayException | If an error during the operation occurs this exception is thrown |