...
You can see we have set up a dynamic-parameter called 'deptId'.
This deptId is used in the requestElement we are building as well as it shows up in the Data Controls panel as a Parameter under the operation.
Now, when we drag and drop an element from the response of the WebService, we will be popped with the default 'Edit Action Binding' popup from ADF:
In here we can create an EL expression going to a value on the page or the a managed bean to get the correct value.
This is how to use dynamic parameters within you request to a WebService.
By default, a dynamic parameter will be exposed in the datacontrol as a string parameter. You can overrule this data type by setting the java-type attribute on the dynamic-parameter element in your DataControls.dcx. Similarly, the #{param.name} placeholder in the xml-parameter will be replaced with the string value of the supplied dynamic parameter value. You can overrule this by setting the xml-type attribute on the dynamic-parameter element in your DataControls.dcx. The xml-type has to be a QName of the xml type in the notation {namespace-uri}name. For example, to map a date you would set java-type to java.util.Date and xml-type to {http://www.w3.org/2001/XMLSchema}date. This exposes the dynamic parameter as a date field so you can use it in things like an af:inputDate and it knows to stringify this data as an xml date.
The actual mapping at runtime is performed by your typeMapper, so the typeMapper you use has to be capable of making the translation from the java type to the xml type. In rare situations, you can specify your own typeMapper for a datacontrol. When not specifying a custom typeMapper, you will be using the default org.adfemg.datacontrol.xml.provider.typemap.TypeMapperImpl. See the toXml method in that source code for all details on supported mappings, including things like binary data.