SWIFT Projects and NetBeans

A Project contains all of the Java CAPS components that you designate to perform one or more desired processes.

• Connectivity Map Editor: Contains the business logic components, such as Collaborations, Topics, Queues, and Adapters, that you include in the structure of the Project.

• OTD Editor: Contains the source files used to create Object Type Definitions (OTDs) to use with a Project.

• Business Process Designer and Editor: Allows you to create and modify Business Rules to implement the business logic of your Project’s business processes.

• Java Collaboration Editor: Allows you to create and modify business rules to implement the business logic of your Project’s Java Collaboration Definitions.

About the SWIFT MX Validation Sample

The SWIFT MX Validation sample demonstrates what types of ”Generic Validations” are done on MX messages and how they are applicable. The sample zip file on the Java CAPS sample site contains the following files and directories for SWIFT MX validation:

• Input Data — MXSample_input.xml.fin – Sample MX message to be read by inbound File Adapter.

• jcdSchemaValidation.java – Java collaboration to validate MX messages against relevant XSD schema.

• jcdGenericValidation.java – Java collaboration to validate MX messages against Extended Validation Rules.

• Output Data – MX_GenericValidationLog_output1.dat – This is a log file for validation results from the jcdGenericValidation java collaboration.

• Sample Project – SwiftMXSample.zip: This is the sample project.

• XSD Data — XSD Schema file () to be validated against the MX input message: RedemptionBuldOrderV02.xsd and swift.if.ia_setr.001.001.02.xsd.

Sample Project

The Project's flow is represented in the Connectivity Map as follows:

Inbound File Adapter –> Schema Validation —> JMS Queue —> Generic Validation —> Batch Adapter, Outbound File Adapter

These are explained further below.

Descriptions of components

• Inbound File Adapter – The File Adapter is used to read MX messages to be validated.

• Schema Validation – Each MX message has a corresponding XSD Schema file. You must use the XSD OTD Wizard to build an XSD OTD based on the schema file. In this collaboration, the logic is to unmarshal the inbound message to the XSD OTD and then to marshal the OTD to String and send the payload to JMS Queue. This process is to ensure the MX message is well-formed and is validated against the XSD schema. For a different MX message type, build the XSD OTD and create this simple collaboration.

  ---

  Note - The sample project chooses the ”RedemptionBulkOrderV02” message and schema to demo the usage. The RedemptionBulkOrderV02 schema is obtained from the SWIFTNet Funds ver3.0 CD, which also contains all element types to be validated in the Generic Validation collaboration.

  ---

• JMS Queue – JMS Queue to hold schema validated messages.

• Generic Validation Collaboration – This collaboration contains a set of generic validation rules, which SWIFT recommends must be applied to an MX message. You can reuse this collaboration to validate all MX Message types. The generic validation rules validate the following identifiers and codes in a MX message:

  • Verifying BIC (datatype: BICIdentifier), against existence in the BIC directory (ISO 9362)

  • Verifying BEI (datatype: BEIIdentifier), against existence in the BEI list on SWIFTNet

  • Verifying ActiveCurrencyAndAmount (datatype: ActiveCurrencyAndAmount), against existence in Currency Code and number of valid decimal digits (ISO 4217)

  • Verifying Country Code (datatype: CountryCode), against existence in Country Code list (ISO 3166)

  • Verifying IBAN Identifier (datatype: IBANIdentifier), against IBAN structure as provided by ISO 13616

  • Verifying BICOrBEI (datatype: AnyBICIdentifier), against existence in the BIC list on SWIFTNet

  • Verifying ActiveCurrency (datatype: ActiveCurrencyCode), against existence in Currency Code list on SWIFTNet

  • Verifying ActiveOrHistoricCurrency (datatype: ActiveOrHistoricCurrencyCode), against existence in Currency Code list on SWIFTNet

  • Batch Adapter – The Batch (Local File) Adapter is used to read XSD files for Generic Validation. Place all XSD schema files in one directory and make sure the name of the XSD file matches the target namespace specified in the MX message. For example, in the sample input file, there is:

    xmlns:Doc=”urn:swift:xsd:swift.if.ia$setr.001.001.02

    Therefore the matching schema file name must be swift.if.ia_setr.001.001.02. Please rename the $ character to _, because the $ character is not considered a valid file name pattern in Java.

    In Java CAPS, you must open the Batch Adapter configuration in the connectivity map (and under the Target Location node) and make sure the directory name for the XSD files are set to Target Directory Name field.

  • Outbound File Adapter – The File Adapter is used to log validation results and error messages in Generic Validation.

    ---

    Note - You can place all XSD schema files in one directory. In Connectivity Map, set the directory name in the Target Directory Name, under Target Location section in Batch Local File configuration window. In Generic Validation, the collaboration will read the input message and locate the associated schema file name, in the directory name specified in Batch Adapter. Make sure the schema file name does not contain any illegal character $. This $ character should be replaced with _ character in file name. For example, schema file name swift.if.ia$setr.001.001.02 should be renamed to swift.if.ia_setr.001.001.02and placed in the target directory.

    ---

Running the MX Sample Project

To run the MX Sample Project, complete the following steps.

1. Import the SWIFT Message Library SAR file.

2. Import the sample project.

3. In the NetBeans Projects window, under CAPS Components Library > Message Library > Swift, right-click on bic.jar and update CT, CU, and FI bic data files.

4. In the Connectivity Map, make sure the directory name and the file name in both the File Adapter and Batch Adapter are valid.

5. On the NetBeans Services window, create a new Environment for the project.

6. Under the project, create a new Deployment Profile and map all components.

7. Build and Deploy the project.

8. Send the input file to the inbound File Adapter and watch for the outbound file.

   ---

   Note - You must build your own XSD OTD and Schema Validation collaboration, based on different MX message types to be validated. You can always reuse the Generic Validation collaboration for all MX messages.

   ---

SWIFT Correlation Repository Sample

The SWIFT Correlation Repository (SCR) is a Java CAPS utility used to visualize SWIFT workflows. In addition, the SCR does the following:

• Reconciles Messages into Transaction Processes

• Provides Message Browsing and Message Monitoring

• Offers services for Duplicate Checking and validation of MX and MT messages

• Allows for Message Repair and Resubmit

Prerequisites

You must have an Oracle database, version 9i or greater to run the project.

Installation steps

1. Install the database schema from the SCR_CreateUser.sql and SCR_CreateTable.sql files (located in the SCR_Create_Cleanup.zip file).

2. Extract the contents of the SampleSCR.zip file into your local drive.

3. Import the SCRProject.zip file.

4. Set the environment variables (as shown in the figure below).

   

5. Create a deployment profile in the SCR project.

6. Create a deployment profile in the TesterGatekeeper project.

7. Deploy both the SCR and TesterGatekeeper deployment profiles.

Preparing an SCR flow

The SCR Workflow follows the tasks, procedural steps, required input and output information, for each step in the business process. The SCR workflow is used to view, manage, and enforce the consistent handling of work. The following figure is an example of a design of an SCR flow.

Designing an SCR flow

1. Start NetBeans.

2. Open the imported SCR project.

3. Choose both a short name and a long name for the flow (example: t2 :: Target2).

4. Choose a string name for each event / message / direction (as shown in the SCR flow example above: TO_SWIFT_INIT).

5. Add the flow name as a new choice in the viewer by navigating to the Viewer on the SCR page, then to the 1TrxList, and then to the pgTrxList.

   1. On the Properties tab, select SelDomain.

   2. Right-click the highlighted area on the design canvas, and select Edit Options. The Edit Options window opens.

   3. Add new flow elements to the properties of the control SelDomain. This project already has default values entered (t2 :: Target2).

Linking the Domain Name and Direction to a Color

You can link the name of a Domain to specific pointer directions and colors within the monitoring application.

1. Extract the SampleSCR.zip file included with the sample project.

2. Link the domain name and the direction to a color by opening the SCR.properties file located in the directory where you extracted the ZIP file.

3. A list of available directions and colors are listed in the SCR properties file. Possible Colored Directions (CD) for message lists include:

   • DEFAULT

   • LGREY, RGREY

   • LBLUE, RBLUE

   • LGREEN, RGREEN

   • LORANGE, RORANGE

   • LRED, RRED

4. Link the Domain to a specific pointer direction and color by using the following Syntax: CD_<Direction String> = <Colored Directions>.

Using the SCR for Monitoring Flows

Applications that send events to the SCR must do two things:

1. Create a message following the input format shown below. Do not use the field whose usage is indicated as “Gatekeeper only”.

   

2. Send the message to either:

   • A file in the \SampleSCR\In location, with a .txt extension and a name starting with Loader.

   • A JMS message to the JMS queue, qSCRInEnv, in SCR/Loader.

Using the Viewer for Monitoring Transactions

1. Use an Internet browser and navigate to the URL http://localhost:8080/scr. The Select Transaction window opens.

2. Use one of the following criteria for monitoring transactions:

   • Select the 10 most recently updated transactions from the drop-down list.

   • Use the domain selector to restrict the transaction list.

   • Search for a transaction with a specific ID.

   • Search for a transaction that contains a message with a specific ID.

3. Click the Search button.

Using the SCR as Gatekeeper

Applications sending events to the SCR as Gatekeeper must do two things:

1. Create a message following the input format (as shown in the previous section)

2. Send the message to the JMS queue “qGKeeperIn” in SCR/Gatekeeper. Make sure to add a JMS topic to the message. A code sample is shown below.

   com.stc.connectors.jms.Message outMsg = 
   jmsPublish.createTextMessage(); 
   outMsg.storeUserProperty( "SCRDestination", "DEST1" ); 
   outMsg.setTextMessage( input.getText() ); 
   jmsPublish.send( outMsg );

3. Subscribe to the JMS queue ”qGKeeperOut” in SCR/Gatekeeper.

4. Subscribe to the JMS topic that you used to publish the message.

Using the Viewer to Repair Messages

1. Use an Internet browser and navigate to the URL http://localhost:8080/scr. The Select Transaction window opens.

2. Select the 10 most recently updated transactions from the drop-down list. Messages that have been held for review and resubmitting (e.g. messages that are duplicates, incorrect, or awaiting approval) are displayed.

3. Select the message you wish to examine and click the Repair button. The Message Repair window opens, displaying detailed information regarding the message.

4. You can resolve the message in the following ways:

   • Correct the message error and click the Resubmit button.

   • Examine a message that requires approval and click the Approve button.

   • Delete the message by clicking the Delete button