De-enveloping scenarios

These are the main scenarios involving combinations of envelope parameters, how the combinations affect processing, and how they determine the overall status of the de-enveloping service.

Inbound processing parameters

A SWIFT Bulk envelope is affected by the following inbound processing parameters during the de-enveloping process. These Bulk envelope parameters have Yes or No values, with the exception of ValidateSchemaName.

PerformComplianceCheck
UseWtxComplianceChecking
SplitTransactions
BatchLikeTransactions
TransformNonCompliantInterchanges
KeepTranslatedDocument
AcceptNonCompliantInterchanges
AcceptNonCompliantTransactions
ValidateSchema
ValidateSchemaName This contains the name of an alternate schema to validate against.

Similarly, an ISO 20022 envelope is affected by the following inbound processing parameters during the de-enveloping process. These ISO 20022 parameters have Yes or No values, with the exception of ValidateSchemaName.

PerformComplianceCheck
UseWtxComplianceChecking
SplitTransactions
BatchLikeTransactions
TransformNonCompliantInterchanges
KeepComplianceMapTranslatedDocument
AcceptNonCompliantTransactions
ValidateSchema
ValidateSchemaName This contains the name of an alternate schema to validate against.

Scenarios for a message with a business header

Each of the following scenarios assume a test case where a message contains a business header and several transactions. Some of the transactions contain validation errors. In each case, assume that PerformComplianceCheck and UseWtxComplianceChecking have been set to YES.

Table 1. Message with a business header
Scenario	Parameter settings	Outcome and notes
For a message with business headers, you want to do compliance checking and transformation. You do not want transaction splitting.	For the bulk envelope, set these parameters: PerformComplianceCheck and UseWtxComplianceChecking to YES. Set Keep translated document Noncompliant interchanges=NO No ISO envelope is required.	You get the transformed output.
Allow splitting to begin for a message that fails the compliance check.	Set PerformComplianceCheck and UseWtxComplianceChecking to YES. Set SplitTransactionsForNonCompliantInterchanges to YES	Transaction splitting might or might not occur, based on several factors. Just because split processing begins does not mean that any splitting is completed. For transaction splitting to complete, ISO 20022 candidate envelopes must be defined in the system and must match the lookup criteria as defined by the Bulk envelope (SenderID, ReceiverID, message type, and AccepterLookupAlias (if supplied).
Allow transformation to continue for a message that failed the compliance check.	Verify that PerformComplianceCheck and UseWtxComplianceChecking are set to YES. Set Change TransformNonCompliantInterchanges to Yes. To keep the output document produced by this transform operation, set KeepTranslatedDocument to Yes.	Transformation continues despite the compliance check failure.
For a message that fails the compliance check, force the overall status of the service to be SUCCESS and launch the good Bulk business process driver.	Verify that PerformComplianceCheck and UseWtxComplianceChecking are set to Yes. Change AcceptNonCompliantInterchanges to Yes. Even if this parameter is set to Yes, splitting does not occur unless SplitTransactionsForNonCompliantInterchanges is set to Yes.
Force the overall status of the service to be SUCCESS, and launch the good Bulk business driver for a message that fails the compliance check, or when split transactions are produced that contain errors.	Change the following parameters to Yes: AcceptNonCompliantTransactions Subsequently, set AcceptNonCompliantInterchanges to No.	When AcceptNonCompliantInterchanges is set to No, then the overall status of the service will be ERROR if any split transaction is found to be non-compliant, or any error occurs processing a split transaction. When AcceptNonCompliantInterchanges is set to Yes, then any nonfatal severity errors that occur during split transaction processing are ignored. Subsequently, the service status is SUCCESS and the Bulk envelope good business process driver is launched.

Scenarios for a message without a business header

Each of the following scenarios assume a test case where a message contains several transactions, but no business header. Some of the transactions contain validation errors.

Table 2. Message without a business header
Scenario	Parameter settings	Outcome and notes
For a message without business headers, you want to do compliance checking and transformation. You do not want transaction splitting.	An ISO envelope is required. Set the following: Set PerformComplianceCheck and UseWtxComplianceChecking to YES. Set Keep translated document Set split transactions to NO. Accept Noncompliant interchanges=NO	You get the transformed output.
ISO 20022 message validation only (that is, no transformation or transaction splitting) where the message does not contain a business header.	Set these ISO 20022-level parameters: AcceptNonCompliantTransactions to No SplitTransactions to No BatchLikeTransactions to No TransformNonCompliantTransactions to No KeepComplianceMapTranslatedDocument to No ValidateSchema to No ValidateSchemaName is not applicable.	The status returned by the ISO 20022 transaction processor will be ERROR, and the ISO 20022 Error Business process is launched for the invalid message.
Split out the good and bad transactions into two batch files, good batch and bad batch. Launch the good ISO 20022 Business Process driver for the good batch, and the bad ISO 20022 Error Business Process driver for the bad batch.	Set the following parameters: SplitTransactions to Yes BatchLikeTransactions to Yes	Transactions are split and the two batch files generated.
Split out the good and bad transactions individually. Launch the good ISO 20022 business process driver for each good transaction, and the ISO 20022 Error business process for each bad transaction.	Set the following parameters: SplitTransactions to Yes BatchLikeTransactions to No	Transactions are split and handled individually.
Identify bad transactions only for reporting purposes, but transform all transactions and launch the good ISO 20022 Business Process driver for each transaction.	Set the following parameters: SplitTransactions to Yes BatchLikeTransactions to No AcceptNonCompliantTransactions to Yes TransformNonCompliantTransactions to Yes	All transactions are transformed. Bad transactions are identified to the generic de-envelope service, and good transactions and handled according to the configuration of the good business process driver. Important: Even though AcceptNonCompliantTransactions is set to Yes, the ISO 20022 transaction processor still reports that bad transactions exist. Therefore, if an overall service status of Yes is desired, the Bulk envelope parameter AcceptNonCompliantTransactions must also be set to Yes.
Alternative schema validation Both the Bulk and ISO 20022 envelopes allow content to be validated against an alternative schema. By default, using WebSphere® Transformation Extender compliance checking will validate the content against the base message schema. However, market practices dictate that some countries place further restrictions on what content is allowed in a message. For such business scenarios, an alternative schema can be applied to perform an additional compliance check.	Set the following parameters: PerformComplianceCheck to Yes ValidateSchema to Yes ValidateSchemaName to the name of the alternative schema checked into the repository Use this approach if you want to use the alternative schema check but do not want WebSphere Transformation Extender compliance checking. Use the parameters indicated, but set UseWtxComplianceChecking to No.	Depending on the envelope and whether WebSphere Transformation Extender compliance checking is used, messages or transactions are validated against the alternate schema, or against both the WebSphere Transformation Extender and the alternate schema.
(ISO 20022 envelope only) Custom WebSphere Transformation Extender compliance check The ISO 20022 envelope allows a custom compliance check to be applied to message content. For example, Funds, CashManagement, and Payments messages have additional rule books that are not mandatory by default, but may be required for a business scenario. While ITXA does not support all rule books, the custom compliance map gives you the capability to implement your own validation.	Set KeepComplianceMapTranslatedDocument to Yes. Set ComplianceMapName to the name of the custom compliance map. If the map contains multiple output cards, the contents of each card can also be persisted as a separate document by setting KeepComplianceMapTranslatedDocument to Yes.	A custom compliance check is performed on the contents of the ISO 20022 envelope.
Message mode and Transaction mode for ISO 20022 Envelope Processing	For an ISO 20022 envelope in Message mode, set SplitTransactions to No. For an ISO 20022 envelope in Transaction mode, set SplitTransactions to Yes. BatchLikeTransactions can be used in both modes. If compliance checking is turned on, two documents will be created: one containing the good batch, and one containing the bad batch.	See Batching good and bad transactions.