Known Issues for Microsoft BizTalk Accelerator for SWIFT (A4SWIFT)
This section contains useful information that may help you avoid errors with Microsoft BizTalk Accelerator for SWIFT (A4SWIFT). The known issues are grouped into the following areas:
Message Repair and New Submission
Printing of a repair document is recorded in the history log even if canceled
If you run the Print command for a document in the Repair Inbox, and then cancel the printing, the printing is still entered into the history log. This occurs when you open the document to be repaired in its InfoPath form, click the Print command on the File menu, and then click Cancel in the Print dialog box. You should ignore the entry in the history log.
A duplicate signature can cause an XLANG/s error message
When a verifier uses the same certificate as a repairer, A4SWIFT suspends the message and indicates in an error message that duplicate signatures are not allowed. However, A4SWIFT also generates another error message with an event source of XLANG/s, indicating that the XLANG/s service has been suspended. You can ignore this message.
Message size can affect repair performance
If you attempt to repair an unusually large XML file, system performance can significantly degrade when you open the XML file in the InfoPath form for the message type. Memory consumption may increase, CPU consumption may decrease, and the process may fail with an error indicating that not enough storage was available to complete the operation.
The last signature used to sign a message successfully will be authenticated by Authenticate Signatures
Clicking the Authenticate Signatures button on an InfoPath form validates the signature for the stage that you are in only if you have already signed the form. Otherwise, it validates the signature for the previous stage, if there was one, and posts the following error:
The signing user is not correctly configured for the <stage_name> role in department <department_name>.
For example, suppose that you are in an approve stage immediately after a verify stage. If you have not yet signed the form as the approver, and you click Authenticate Signatures, A4SWIFT authenticates the signature that the verifier used, not your approver's signature, and posts the preceding error.
A4SWIFT cleanup tool doesn’t delete templates
The A4SWIFT cleanup tool doesn’t performs the following operations:
Removes all MT templates from MRSR site
Removes all agreements and partner profiles from MRSR site
Removes all users, roles, and departments
Unregisters the A4SWIFT BizTalk Server from the MRSR site
The A4SWIFT_MRSRDepartment property is set to an empty string for a message that did not parse
When the message-repair orchestration routes to the MessageBox an unparsed message that has been fixed, it will set the A4SWIFT_MRSRDepartment property to an empty string and promote it. A send port will not be able to subscribe on this property.
Cannot save a department if the SSO service has been stopped
If you try to add a department when the SSO service is stopped, you will receive an error indicating that the Primary SSO server <machinename> failed. Check that SSO is configured and that the SSO service is running on that server.
A department name must not contain the character "~"
A department name that contains the character "~" will cause issues with the A4SWIFT database.
Signing Infopath forms
The signing of InfoPath forms needs to be done manually.
Security
Mixing trusted and untrusted hosts can enable spoofing
It may be possible to spoof SWIFT-bound messages from other non-trusted BizTalk Server host applications. This is only a problem when running in mixed-trust mode (when trusted hosts and untrusted hosts run applications in the same BizTalk Server group). You can mitigate this risk by using party-resolution pipeline components to identify the source of the SWIFT-bound message. This is not necessary when running in a fully trusted environment or for the majority of usage scenarios. You should follow the BizTalk Server guidelines for building secure applications when mixing trusted and untrusted hosts.
Miscellaneous
The CacheEntries setting may be reset by a Setup program, affecting performance
The CacheEntries registry key determines the maximum number of rulesets cached by the Business Rule Engine Update service. The BizTalk Server Setup program sets CacheEntries to 32 by default. The A4SWIFT Setup program changes HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \BusinessRules\3.0\CacheEntries to 512 for optimum performance. However, in certain circumstances, CacheEntries may be reset automatically. This may affect system performance.
Rule Engine updates may change CacheEntries from 512 to 32. After installing a Rule Engine update, manually reset CacheEntries to 512, if necessary.
Even though the A4SWIFT Setup program sets CacheEntries from 32 to 512, uninstalling A4SWIFT does not reset CacheEntries from 512 to 32.
For more information, see the "Rule Engine Configuration and Tuning Parameters" topic in BizTalk Server Help.
Building a pipeline project may result in a large number of warnings
When you add the SWIFT assembler to a send pipeline, or the SWIFT disassembler to a receive pipeline, and then build the pipeline project containing those pipelines, you may receive a series of warnings related to the pipeline components. These warnings indicate that Visual Studio could not find dependencies. You can correct the condition leading to these warnings by changing the Copy Local property of the SWIFTAsm or SWIFTDasm assembly in the reference folder, as follows:
In Solution Explorer of Visual Studio, expand your pipeline project, and then expand the References node.
Under the References node, select the SWIFTAsm assembly and/or the SWIFTDasm assembly.
In the Properties pane, change the value for the Copy Local property to False.
Right-click your pipeline project, and then click Build.
Note
You should not see any warnings about dependencies not being found.