Invoking Our Framework from the ProductX Web Client

The implementation examples for the server components I just went through would not be complete without the sample code that drives them. The code snippet in Listing 6.20 shows how you can generically prepare and call into the Commercial Framework using the helper methods shown. Here you begin by preparing a Packet object (DataSet with XML schema) on the client, fill the Packet with instance data from any external interface, and send it to the server with an entry-point method (Execute method) to invoke one of the business methods provided by ProductX. The ServerExecute method takes any "action" and relays it to the server for a response. Several helper methods have been provided, such as PreparePacket(). PreparePacket() simply calls GetSchemaTemplate() to retrieve a product schema (in this case, the ProductX XML schema), fills the DataSet with instance data as input from a Windows interface, and finally calls the Execute method with an action of SaveTransaction.

Listing 6.20 The client-side driver code for the running transaction against our framework.

 private DataSet ServerExecute(string sType, string sAction, string sTransactionTableName, bool bDisableOutput, out StringBuilder sbOutput, out StringBuilder sbLog, out long lTransTime)    { . . .       try       {          localhost.WebServiceFactory sf = new          localhost.WebServiceFactory();          . . . ds = PreparePacket(false, sType);          sf.SetMetaInfo(ref ds, sType, sAction, "1");          . . .       sf.Credentials = new NetworkCredential(. . .);       dsReturn = sf.Execute(ds);       if (dsReturn != null && !bDisableOutput)       {       . . .       /* process response */          }       }    . . .    return dsReturn;    } 

The following shows one of the child screens used for setting up and testing the ProductX server and Commercial Framework. Figure 6.5 shows the input for all required ProductX fields to provide the user a means for saving a ProductX transaction. The ProductX data is entered, the packet prepared, and the ProductX transaction is saved using the steps briefly summarized in this chapter. Once the ProductX transaction is saved, it can be reviewed and edited or a final ProductX document can be created. An example of this ProductX output is also shown in Figure 6.5. Here you can see an example of the type of financial output a bank (processor) would receive from a merchant when ProductX transactions are processed . If you have ever used automated bill payment through your bank or had your paycheck automatically deposited, your transaction output would look something like this.

Figure 6.5. The framework administrative interface.

Figure 6.5 shows an example for setting up and testing the ProductX application. The production ProductX application will process information from whatever financial application is used by that particular merchant. The interface depends on the financial package the merchant is using, such as SAP, Great Plains, or CRM, to name a few. From here, the financial packet sends the transaction in a fashion similar to the driver code shown in this section.

Once the ProductX server has the transaction, it can save it and schedule its processing at any time. Typically, ProductX processing is done in batch form on a nightly basis driven by a scheduler, such as the one provided by ProductX. In Figure 6.6, several scheduled items can be seen, such as the action to pick and receive a confirmation file from the bank. This action is automatically generated by the ProductX once a ProductX output file has been successfully sent to a processor. This allows any transmission errors to be processed and determines whether it is necessary to resend the ProductX output to the processor.

Figure 6.6. The scheduling interface used to show which batch files have been to financial processors and are prepared for receiving a confirmation file. A WinForm SmartClient was used here.

Figures 6.6 and 6.7 show you configuration screens in the ProductX admin utility. This is used to set up a particular processor's configuration information so that the ProductX transaction can be correctly formatted. It also provides the necessary configuration in order to communicate to the processor, such as FTP IP and security information (because most financial files are actually sent via FTP).

Figure 6.7. Another admin screen used for configuring financial processors on the fly.

ProductX has its own standard guidelines but how each processor handles a ProductX transaction is somewhat independent of that standard. Even items such as processor configuration, merchant configuration, and general framework setup make use of the basic framework. Creating configuration information allows Company ABC to "eat its own dog food" and use the same facility to set up the application server that is used to actually run the transaction in production at a customer site.