The initial SDD2 message. Value MUST be one of the CUCBC defined values. Those are NOT defined in an enumeration, since we expect the list to expand over time. Value SHOULD be unique within the SDD2Requests sent by the source. It is used to associate a SDD2Reply/ReplyResponse pair to the initial SDD2Request/Response pair. Identifies the sender of the message. See documentation for ServiceNameType. In particular, this element may include the "OnBehalfOf" attribute, ( for instance when either MDi or MD5 is handling a message created on one of the Credit Union sites. Identifies the target of the message. See documentation for ServiceNameType. Should NOT include the "OnBehalfOf" attribute. Payload for this Request. Must be in the format that the AppId implies. If that format is defined by some XML Schema, this payload MUST use XML escape characters appropriately. The response to a specific instance of an SDD2Request. Value MUST match that of the associated SDD2Request. Value MUST match that of the associated SDD2Request. This value is set by the application processing the Request. The value should be "Pending" if all the processing done so far has been successful AND the target will be sending an SDD2Reply when all processing is finished The value should be "Complete" if all processing was successfully completed - the ResponseBody may include application specific information. The value should be "Failure" if some processing was not successful - in that case the ResponseBody should contain application specific information about the problem. OPTIONAL ( as far as SDD2 is concerned ) Payload for this Response. The application may require something here, and if so, this must be in the format that the AppId implies. If that format is defined by some XML Schema, this payload MUST use XML escape characters appropriately. The result of processing an "asynchronous" specific instance of an SDD2Request, sent from the RECIPIENT of an SDD2Request back to the sender. NOTE that MOST applications will not expect one of these. The only one that currently does expect one is the bulk mail application. Value MUST match that of the associated SDD2Request. Value MUST match that of the associated SDD2Request. Identifies the sender of the message, which should be the destination of the original SDD2Request. See documentation for ServiceNameType. Identifies the target of the message, which should be the source of the original SDD2Request. See documentation for ServiceNameType. Should NOT include the "OnBehalfOf" attribute. This value is set by the application processing the Request. The value should NEVER be "Pending" in a SDD2Reply. The value should be "Complete" if all processing was successfully completed - the ResponseBody may include application specific information. The value should be "Failure" if some processing was not successful - in that case the ResponseBody should contain application specific information about the problem. OPTIONAL ( as far as SDD2 is concerned ) Payload for this Reply. The application may require something here, and if so, this must be in the format that the AppId implies. If that format is defined by some XML Schema, this payload MUST use XML escape characters appropriately. The response to a specific instance of an SDD2Reply. This value is set by the application processing the ReplyResponse. In general, the value should be "Complete" - the receiver of a Reply is not expected to do anything more than save it for reference. The value should be "Failure" if some processing was not successful - e.g. there was a failure when saving the Reply to a database. In that case the ResponseBody should contain application specific information about the problem. The value should NEVER be "Pending" in a SDD2ReplyResponse. OPTIONAL ( as far as SDD2 is concerned ) Payload for this ReplyResponse. The application may require something here, and if so, this must be in the format that the AppId implies. If that format is defined by some XML Schema, this payload MUST use XML escape characters appropriately.