Editar

Compartilhar via

Message Repair Process

  • Artigo

By default, BizTalk Server suspends failed messages in the suspended queue of the MessageBox database. This process handles failed messages separately from successful messages. Using this default mechanism, however, you have a limited ability to retrieve failed messages and repair them. The Message Repair and New Submission feature of A4SWIFT enables an A4SWIFT user to repair a message and resubmit it. Another A4SWIFT user can then verify the repairs, and a third can approve the repairs.

Note

In this context, an A4SWIFT user is a user that performs a role in a departmental repair workflow. This A4SWIFT user is defined, and associated with a certificate, in the Users link of the Profile Web Client. This A4SWIFT user is not the same as a Windows user account, as defined in the A4SWIFT Users group in the Windows Computer Management utility. The person functioning as an A4SWIFT user must have a Windows user account so that they can use that account's certificates when submitting a message. However, that person can also serve as other A4SWIFT users: repairer, verifier, approver, or creator. For more information, see Creating Departments and Roles for Message Repair and New Submission.

With this repair workflow, A4SWIFT does not suspend a failed message. It performs additional processing on the failed message, and then drops the message into the MessageBox, just as it would a successful message. The repair orchestration drops the message into the A4SWIFT MRSR site, where users can perform their functions in InfoPath forms.

Message Validation

Message Repair and New Submission sends any message failing the following validation to MRSR site for repair:

  • Structural validation performed by the flat file parser (unparsed messages)

  • Data validation performed by the XML validating reader

  • SWIFT network and usage rule validation performed by the Business Rule Engine (BRE)

    A4SWIFT collects any errors encountered during validation in an error collection object that travels with the SWIFT message. The repair process includes serializing error information into XML and attaching it to the message as an error part. This processing also includes marking the message with a promoted property that indicates that the message has failed validation (A4SWIFT_Failed==True), and another promoted property that reports the error counts for each validation stage. The resulting multipart message consists of the following:

  • A body part containing the failed message

  • An error part containing the error-collection XML

  • Promoted properties indicating the failure state

Message Repair

The MRSRDepartmentRule business rule within the MRSRDepartmentPolicy determines which department will handle the failed message. The message repair orchestration starts the repair workflow by routing the message to an inbox associated with the repair role in the department. The A4SWIFT user performing the repair role opens the message in the InfoPath form, repairs the message, and then signs and submits it. The orchestration routes the repaired message to each of the repair, rekey verification, or approval roles, and after the workflow has successfully completed, routes the message to the send port.

In addition to validation, A4SWIFT checks the signatures on the message to determine the following:

  • The users in the repair workflow belong to the same department

  • Each user has signed just once

  • The sequence of roles corresponding to the users matches the sequence in the workflow defined for that department

    For more information about departments, see Creating Departments and Roles for Message Repair and New Submission.

    A4SWIFT also enables you to repair unparsed messages. However, A4SWIFT performs different processing on a repaired unparsed message. For more information, see Repairing Unparsed Messages.