ProductX and the Commercial Framework

To understand a little about the actual product and how I applied each pattern, you must first understand a little about what ProductX does. ProductX and the framework on which the product runs (referred to as the Commercial Framework from this point forward) were the first introduction in 2001 for Company ABC, Inc. to this .NET effort. The framework was first developed to help bridge an existing product suite from Company ABC and to develop from the ground up the "plumbing" components for all future .NET products to use and eventually migrate to. The architecture was to house all .NET products in enterprise fashion. After all, these applications were installed on an application server in a Web form. The architecture would need to include all of the typical requested elements of a mission-critical application: scalability, reliability, failover, high transactional throughput, expandability, etc. Using a Web form, load balancing, session state caching, server clustering, and asynchronous Web services features, to name a few, we were able to achieve these aforementioned critical elements.

But where did we start? We first exercised a risk matrix and applied a high-risk mitigation plan to a set of proof-of-concept (POC) delivery vehicles. The first POC would involve a bridge to the existing COM architecture. A path was needed so that a smooth migration from the older products housed in COM to the new would be possible. A bridge was developed so that the existing products, which were all C++/COM-based, could easily be executed through .NET with minimal migration complexities. The second piece to the mitigation plan was to build all aspects of a framework so that pure .NET products could use a solely .NET platform without using the bridge. These are the typical plumbing pieces that I'm sure you are familiar with (e.g., exception handling, data access, caching, logging, business managers, etc.).

The framework itself was a major undertaking because all existing core COM framework functionality was to be eventually rewritten in C#. This would give Company ABC a framework that would be 100% managed code, all written in C# with a " back-door " option of running seamlessly through a bridge for any functionality not yet ported to .NET. This strategy not only gave the company some insurance that the .NET product could be delivered sooner rather than later but it also provided a smoother migration path for production because so much code had already been written and continued to be written in C++ and COM. Although the new framework would be a complete redesign and reimplementation, the older framework had to be leveraged. There was just too much COM/C++ code to be migrated in a short period of time (6 months to a year). This bridging effort was how the Product Manager idea was created and what drove our generic Service Fa §ades from the get-go.

As you have probably experienced, migrating an entire company to one technology, especially to something as new as .NET, is a major undertaking. The only safe path to success in this scenario is to provide as many smaller victories as possible along the way. Migrating to the platform for every product at once is risky and unnecessary. The Microsoft .NET framework and Visual Studio .NET make this transition much smoother than migrations I have experienced in past (the 16-bit to 32-bit jump comes to mind). Whether the code needing to be migrated was C++, Visual Basic, or even Java, the "interop path" is well paved in .NET.

• Through managed C++ extensions, we were able to move certain pieces of existing C++ (compiled in VC++ 6.0) to .NET.

• Through COM Interop, we were able to bridge all COM functionality, leveraging XML as the meta-language .

• Through SOAP, we were able to connect to older, "hand-rolled" XML Web services used in the older framework.

• Through the ease of using J#, we were able to migrate existing Java source code to the final C# destination, allowing us to leverage hundreds of lines of code and to do it in small " chunks ." A full FTP client written in C# and migrated from Java is included with this book and demonstrates the ease at which thousands of existing Java samples (with code) can be leveraged using J# and C#.

To summarize, the three major goals we had in providing a .NET framework were:

1. Provide a smooth migration path for existing COM products using a "product bridge." For example, this is where the Product Manager pattern came into play, and its implementation is shown here.

2. Build the foundational features required for native .NET products to run under . This included components and services used for data access, error handling, custom logging, presentation, template coding, containment, aggregation, decision making, reporting, scheduling, business rules inference, etc. ”basically all of the goodies required to build a true enterprise system. Some of this, such as data access and decision making, are featured here.

3. Exploit some of new features of C# and the .NET Framework . This included the goal of not only duplicating framework functionality but also leveraging some of the "cool stuff" .NET has to offer, such as Web services, dynamic invocations (reflection), XML-based configuration, XML-based data access using ADO.NET, etc.

Item 3 above was important for several reasons. Not only was current framework functionality rewritten but new services were also added that exploit what .NET has to offer; otherwise , why do it? Plenty can be said about the fact that C# solutions can be delivered much quicker than traditional C++ or even Visual Basic applications. But this engineering rhetoric is harder to sell to a customer.

For management, the time to market for a C# application is a tremendous value. Of course, this assumes that your development skills are up to speed. Getting everyone on board takes time, and that first leap is never quite as smooth as anticipated, so you had better have business reasons for migrating or you can forget it. Also (and more practically), it would have been quite silly simply to replicate features without taking full advantage of things such as Web services, XML configuration, disconnected data sets, SOAP integration, and all of the other niceties of running in a managed environment. Such undertakings, especially for companies the size of Company ABC, are rare. Framework projects typically do not generate revenue, so this particular effort was definitely considered "R&D." For us, the quicker Company ABC had an actual sellable product "out of the door" that ran in the new Commercial Framework, the better. Besides developing the framework and the bridge, a product had to be selected that would run on it and be written completely in .NET. An electronic check-processing application called ProductX was just that product.

As mentioned, R&D for a small company is an expensive undertaking. Company ABC took on some risk by devoting several resources to a non “revenue generating project. It also took on the risk of moving an entire framework from C++ to C# and Managed C++. Companies experiencing the jump from the 16-bit to the 32-bit world had similar issues. Fortunately, today many of those migration nightmares have been overcome through better practices and especially better tools. In a nutshell , it is much easier today to migrate to a new world such as .NET than it ever was in the world of Windows from DOS. That said, it was still a primary goal to get a minimal framework up, get it to talk to the existing COM framework, and develop a simple yet sellable product to run natively within it.

It would not be until the product could run in the new framework that the business benefits of this effort would be seen. ProductX was the first 100% .NET product for Company ABC and was not simply designed as a Web service wrapper around another technology core. Like the new framework itself, all of ProductX is written in C# and ASP.NET and is designed to exploit fully all of what .NET has to offer, including Web services. How these .NET features were leveraged and what patterns were used is the subject of this chapter. ProductX was chosen because Company ABC did not have a product for processing electronic check transfers (it had solely focused on payment cards to this point); this was a new market, and this product could be developed rather quickly. This was the perfect product benefit combination for an already relatively expensive R&D undertaking.

What is ProductX?

If you've ever paid using your credit card over the Internet or had your paycheck automatically deposited, there is good likelihood that it may have been handled by one of Company X's products. Using one of the many financial services backbones (e.g., FDMS), Company ABC's products may, one day, be responsible for ensuring your paycheck electronically appears each pay period. ProductX uses what is called an Automated Clearing House (ACH). This provides the format and rules used to handle "electronic checklike" capabilities using a regulated and standard means of transferring money between two parties. ProductX is regulated by an organization called NACHA (the National Automated Clearing House Association). A visit to NACHA's Web site at http://www.nacha.org will tell you more about the association:

NACHA represents more than 12,000 financial institutions through direct memberships and a network of regional payments associations, and 650 organizations through its industry councils. NACHA develops operating rules and business practices for the Automated Clearing House Network and for electronic payments in the areas of Internet commerce, electronic bill and invoice presentment and payment (EBPP, EIPP), e-checks, financial electronic data interchange ( EDI ), international payments, and electronic benefits transfer ( EBT ).

Challenge 6.1

Why would any company commit to converting its existing commercial application and framework to .NET and C#?

See the Competitive Advantage section later in this chapter to see why Company ABC did.

Why Should Consumers or Businesses Use this Type of Product?

Taking more than one form of payment increases the value of a vendor, whether in retail or commercial business. At the other end of that offering lies the cost of transacting a payment, and the businesses that offer any format must take into account that cost. For the consumer it's choice; for the retailer it's cost. Imagine a world without any form of payment other than cash. Aside from the savings you might have in all of the interest you pay, your options would be extremely limited. Taken in another direction, imagine a world without personal or commercial checks. This simply points out the need for variety of options in the payment-collecting process. By offering your customers the ability to pay directly from their checking or savings accounts, you are extending the flexibility of their buying power. By using this product, companies can remove the financial limitations of accepting payment from only a few available sources.

Consumers need options, and businesses need a cost-effective and consumer-friendly means of providing that option. Credit cards (or payment cards, if you like) are only one means of a fund transfer conduit. The other major choice is the check. ProductX's electronic check provides the adjunct to the payment card world. Soon with ProductX, electronic fund transfers will be commonplace, and you will not be able to imagine a world without it. For those who perform most of their financial transactions on the Internet, this has already become an indispensable option. I don't want to think about not having my paychecks automatically deposited or not having the flexibility of paying my mortgage by phone or Internet. I don't like using credit cards, so for me this is an incredible option. For others it should be too, because it is a proven fact that more people have checking accounts than have credit cards. Many more people have savings accounts or are simply trying not to use credit cards, due to the high interest rates.

The Federal Reserve Board's automated check mechanism has been around for years , but until recently only the largest companies and banks had access to it. Company ABC, Inc. brings this option to businesses that accept checks and those who pay by check. In turn , the benefits of this option are passed on to those consumers who use it as their primary financial vehicle. It does not matter whether your business is a small "mom-and-pop shop" or a Fortune 500 enterprise; automated checking can save thousands of dollars on both ends. With Company ABC's products, electronic checks provide more options for businesses customers and will save money through cheaper transaction costs over both payment cards and manual exchanges.

To summarize what this product can provide:

• Reduced returns for invalid accounts

• Lowered transaction costs versus other forms of payment

• Substantially lower product-return fees

• Quicker availability of funds using direct deposit

• Transactions from savings as well as checking accounts (you currently can't deduct from a savings account using NACHA-formatted transactions)

• Reporting options and the ability to optimize cash flow projections

• Elimination of debiting and payment guesswork and the payment synchronization that must occur

• Travel time cost reduction (unnecessary trips to the bank, etc.)

• More efficient receivables management

A .NET Product in the Financial World

These days, if a business offers a new convenience-oriented service to consumers, take a closer look! Chances are that electronic checking may somehow be involved in the company's operational support mechanisms. For example, consumers who elect to pay monthly for things such as subscriptions typically must agree to pay using Electronic Funds Transfer (EFT). In this case, EFT is simply a fancy name for the use of automated check debit transactions.

Checks Superior to Credit Cards

The discount rates and labor costs associated with credit card transactions effectively reduce the profitability ratios of the business, especially when contrasted with automated check payments. Further, once customers have exceeded their annual credit allowances, the company must manually generate additional monthly credit card transactions. As a result, many companies prefer that members utilize the monthly automated check payment option. To encourage signups, these companies are now providing training to customer support staff in the features and benefits of using the automated check payment option. Clearly, when contrasted with other payment methodologies, automated check-based payment processing can offer a company greater amounts of information to monitor the cash flows of its business more effectively. For most companies, the automated check is truly an accounts receivable "savior" that is more than just an efficient mechanism for payment collections.

In 1996, securities dealers moved from a 5-day to a 3-day settlement period for securities purchases (called T+3 ). Some firms began to view the automated check as an attractive alternative to "a check in the mail" for receiving timely payments. In contrast, the mutual fund industry embraced the automated check system long ago, because it has always essentially had a "T+1" settlement period. In other words, payments and/or instructions for mutual fund purchases received on one day usually means the money must be in the mutual fund on the following business day. The automated check can be a perfect vehicle for accomplishing this. Shareholder instructions for purchases received during the day are converted into an automated check debit file and sent that evening for transmission to the firm's originating bank; settlement the next day provides the money for the mutual fund.

Automated Check Payments Reduce Operating Expenses

By utilizing the automated check system for every appropriate payment transaction, many companies have been able to reduce operating expenses.

The Technology and Rules Behind Automated Check

This checking network is a highly reliable and efficient nationwide batch-oriented electronic funds transfer system governed by the NACHA operating rules, which provide for the clearing of electronic payments for participating depository financial institutions. The American Clearing House Association, Federal Reserve, Electronic Payments Network, and Visa act as operators. These are the central clearing facilities through which financial institutions transmit or receive automated check entries. The financial institutions are the banks or processors that receive and send the payments for those parties participating in an automated check transaction. Figure 6.1 illustrates an overview of the roles taken in electronic checking.

Figure 6.1. A brief overview of the roles involved in an electronic check transaction.

An automated check transaction can include the following:

• Direct deposit of payroll, Social Security, and other government benefits, and tax refunds

• Direct payment of consumer bills such as mortgages, loans, utility bills, and insurance premiums

• Payments between corporations

• Electronic checks as part of accounts receivable or accounts payable departments

• E-commerce payments (Internet- related payment options)

• Federal, state, and local tax payments

• International transactions

• Interdepartmental deposit consolidations

Figure 6.1 depicts the roles for the following parties:

Originator . Any individual, corporation, or other entity that initiates entries into the ACH Network.

Originating Depository Financial Institution (ODFI) . A participating financial institution that originates check entries at the request of and by (ODFI) agreement with its customers. ODFIs must abide by the provisions of the NACHA Operating Rules and Guidelines.

Receiving Depository Financial Institution (RDFI) . Any financial institution qualified to receive check entries that agrees to abide by the NACHA Operating Rules and Guidelines.

Receiver . An individual, corporation, or other entity who has authorized an Originator to initiate a credit or debit entry to a transaction account held at an RDFI.

Challenge 6.2

What were some of the first patterns used, and why this application? What patterns are typically the first to be utilized when designing a framework from scratch?

See the Competitive Advantage section later in this chapter for the answer to both of these questions. HINT: Chapters 2 and 4 .

Electronic Check Web Servicing

Our electronic check product, ProductX, is one of many .NET products from Company ABC, Inc. that provides payment processing. What makes ProductX special, aside from the fact that most of it is written and designed using .NET, is that it fully leverages a custom framework that leverages the patterns presented in this book. As mentioned earlier, the Commercial Framework was designed to provide the plumbing for all .NET payment products going forward. This is the .NET framework upon which all of Company ABC's products, even those written in C++, will eventually run, once migrated fully or through a provided bridge. As of writing this book, many Company ABC products still exist in C++ and COM.

To leverage those "legacy" applications fully, I designed a bridge from the .NET framework to the older framework using the COM Interop services from .NET. By the time this book is published, many of those products will have already been fully migrated over to .NET with much of the code modified using managed C++ extensions or rewritten completely in C#. For all new product development moving forward, C# will be the language of choice. Company ABC is committed to making C# the language that is used, not only for high-level pieces such as the code used at the presentation, business, and data tiers of an application but for low-level pieces, as well. For example, the FTP server and client components were all written using C#. As an added bonus, I've included the full source code for this FTP component with the book. This piece is currently running in production and can easily be used to create a full-fledged FTP client in C# (currently it does not have a graphical interface and is Web services-driven).

As stated earlier, ProductX for electronic check processing is only one piece of the total product suite puzzle available from Company ABC, Inc. Others include payment card processing, reporting, and other financially related services provided by integrating electronic payment capabilities with features of accounting packages such as SAP, Microsoft Great Plains, or Microsoft CRM (Customer Relationship Management), to name a few. The ProductX product (or any of the payment products) constitutes more than just the handling of financial transactions on the back end. The competitive advantage of each of the financial products mentioned here lies in how well they integrate with accounting packages (written from other parties). Such an example is shown in Figure 6.2, depicting the user interface integration of ProductX with Microsoft CRM.

Figure 6.2. Electronic check entry screen as seen integrated into the Microsoft CRM Sales Force Automation Tool. This is a Web form screen using server-side controls in ASP.NET.

Microsoft CRM is a new sales force automation tool from Microsoft's Business Solutions Division, which is part of the recent Great Plains acquisition. By integrating the front end of this product into CRM, ProductX gains the front-end vehicle for driving electronic check transactions for customer service or sales representatives using that particular product to complete a money transfer. With CRM, users can manage customers and products, and when the time comes, they can pay for product using their financial information and ProductX to the drive the money transfer. For the thousands of companies using SAP, Company ABC has built a company around being one of few payment processing vendors for SAP. You can't have a back end without a front end to drive it. Company ABC is in the business of providing that back end with just enough GUI integration pieces to complement preexisting accounting packages.

Figure 6.2 shows what this product looks like from Microsoft CRM's Orders screen. With Microsoft CRM, ProductX provides a simple means of accepting payments for sales orders using electronic checking instead of credit cards. The following screen is automatically populated from the Orders screen from within CRM, using the current ID, Customer Name, Amount, and for some customers; the account numbers . Once populated with the required fields, the user simply selects Submit, and the checking transaction will be saved using the Commercial Framework on the back end. Then each night via customized schedule, all unprocessed checking transactions will be retrieved from the database, and an electronic check data file will be prepared and sent to one of many configured NACHA-compliant processors.

Once prepared, the transaction file is sent (typically FTP) to one or more financial processors associated with this particular customer (or merchant). Settlement of funds typically takes three days, and a confirmation report is then sent back to the originating merchant. Both client-side and server-side validations will occur to guarantee that each information field is correctly received. This product currently integrates with SAP and CRM. CRM is completely Web-based, and all integration typically uses an ASP.NET front end to gather any information. For SAP's integration, the user interface design is created using the development environment of SAP and is slightly different in appearance than the interface shown in Figure 6.2, although it is still Web-based.

The power of ProductX and of most of the Company ABC's product suite is on the server. Once integrated into an existing financial front end, all payment processing happens behind the scenes using the server plumbing provided to each merchant by Company ABC. Here, transactions are managed, sent, received, and reported on so that in the end, the merchant saves money transaction by transaction and receives the other many benefits awarded by each product in the payment suite. For example, if a company uses Microsoft Great Plains to manage customer receivables, ProductX can help automate the receipt and transfer of all necessary funds by providing a means to transfer cash electronically. If that same accounting package is used to manage employee payroll, ProductX can automate the transaction of depositing those funds each pay period.

ProductX can handle electronically and seamlessly anything that can occur with a check, saving the customer money. For credit cards or any payment card option, Company ABC offers other product options, as well.

Now that you have a brief overview of the ProductX product, let's discuss its architecture. To do this, however, you first have to understand a little about the Commercial Framework.

Each product running on the .NET framework handles different aspects of a "payment processing" scenario, with each product playing a specific role. Each provides different options, benefits, and technological scenarios. Each is governed by different rules, and those rules are constantly changing, as must the products that manifest their features. The payment card and ProductX product provided by Company ABC will be an ever-changing and dynamic product suite. Microsoft's .NET and the framework I've built using it has simplified the process of keeping those products up to date. This robustness and ease of maintenance is the entire reason for going through the trouble of using some of the patterns I'm about to discuss.

You should now have a very high level understanding of the ProductX product featured here, and now I can discuss how it was built. Now it's time to look at the architecture behind the framework and how the patterns in this book were applied to its backbone. I would also like to talk a little about how ProductX was integrated into one of the accounting packages Company ABC supports and show what patterns were used during process. It's time to apply design theory to implementation practice.