This service alters the values of an existing synchronous or asynchronous listener notification. You must populate the input pipeline according to the table below before calling this service. To obtain a list of supported template and schedule properties, call the service wm.art.dev.notification:fetchListenerNotificationTemplateMetadata.You must disable a listener notification before updating its properties, using the disableListenerNotification service. For more information, see the webMethods Integration Server Built-In Services Reference for your release.

You should be familiar with the differences between synchronous and asynchronous listener notifications, as described in wm.art.dev.notification:createListenerNotificationNode.

Once you configure a synchronous notification, you cannot convert it to an asynchronous one. Nor can you convert an asynchronous notification to a synchronous one.

In the table below, two input parameters apply to both synchronous and asynchronous listener notifications: listenerNodeand notificationSettings.For each of these parameters, the service attempts to overlay the given values onto the notification's current values. The resulting set of merged property values are used to reconfigure the notification.

For instance, you can change the listener resource used by the notification by providing a new listenerNodeinput parameter. If you omit this parameter, the notification continues to use its current listener. If you are changing only the listener resource, it is not necessary to provide the notificationSettings or any other input parameters.

For an example of setting values within the pipeline, see wm.art.dev.notification:createListenerNotificationNode. In particular, note that when constructing the notificationSettingsparameter, the value of the systemName metadata attribute is an adapter-specific internal name of a property. You should substitute the actual internal system property name for the systemName placeholder. (You can fetch the name using wm.art.dev.notification:fetchListenerNotificationTemplateMetadata.)

For synchronous notifications there are three additional input parameters that may be provided: serviceName, requestRecordDef,and replyRecordDef.The first one specifies the node name of a separate service to be invoked by the notification at run time. If you omit this parameter, the notifications still retains the current value of the parameter. The latter two parameters view document record definitions that the notification uses to format messages when communicating with this service. You can modify these definitions by providing requestRecordDefor replyRecordDe f (or both). You populate these parameters in the same manner that you populate notificationSettings(as described above). The difference is that the fieldNamesand fieldTypesproperties each view an array of String. There is a one-to-one correspondence between the elements in these two arrays.The values assigned to these properties should correspond to fields that the notification class and the invoked service will actually use when communicating with each other. Note that this service has no way to verify this assertion. If you mis-configure either record definition, the consequence may not be manifested until run time.

You can use the input parameter publishableRecordDef to redefine the structure of an asynchronous notification's output document. You configure this parameter in the same way that you configure requestRecordDefand replyRecordDef for synchronous notifications. The same caveats apply as well: you are responsible for knowing how to define this document such that it conforms to the notification's expectations.

Unlike notificationSettings, listenerNode,and serviceName,the parameters requestRecordDef, replyRecordDef,and publishableRecordDefare used to replace their existing counterparts in their entirety. The service does not attempt to merge the values in these parameters with the notification's current values. For instance, if you want to redefine a synchronous notification's reply record definition, you must define the entire record in the replyRecordDefinput parameter.

When specifying property valuesyou must provide values that conform to the underlying data types of those properties.

Be aware of any resource domains registered by the notification, and set the notification's properties according to the interdependencies between resource domains. Knowledge of these interdependencies is adapter-specific, and beyond the scope of this service. This service does not interpret resource domains.

None.