The Challenge
Last year, I was given an RFP to implement a Digital Asset Management System (DAMS) for a leading Japanese automotive manufacturer based in Gardena, California. The general system requirements asked for a unified system that would provide users across North America with access to digital assets for use in advertising and branding efforts. My first thoughts were, "Okay, I'll go and find vendors who provide this service or find a packaged application that addresses the requirements outlined in the RFP."Piece of cake, right? Not really.

After a week of research, I came across three companies that offered such a service. But the prices for these services were outrageous! Not only was there an initial setup fee, there was a per-seat user license. When calculating the cost for the thousands of dealers, vendors, and regional and corporate users that would be accessing this site, we knew that this was not an option.

We were coming down to the wire on the deadline for the proposal and we had yet to select our proposed solution. Then the project manager asked, "How long would it take to develop a custom digital asset management system for the client?" I was taken aback! In the past, I have always been pushed to find a prebuilt or customizable solution. "Depends on a few things - most importantly the platform," I responded.

The project manager mentioned that the client was predominantly a Java shop; however they were in the process of implementing .NET into their infrastructure.

"Well, if we choose Java, it will take anywhere from 12-18 months. With .NET, it will take approximately 8-10 months," I responded. This was not going to work, since the RFP asked for a six-month timeline on the implementation of the proposed solution. Well, we can deliver a custom enterprise solution to them in less than six months," I informed the project manager. "Really?" he asked. "Yes…" I replied, "with ColdFusion."

The Obvious Choice
After some deliberation, I was able to convince the project manager to pitch a custom solution utilizing ColdFusion. However, I was to deliver a demonstration of the proposed system when the proposal was due - in two weeks. No sweat!

Ready to have some fun, I returned to the RFP and began to access the functionality required of the proposed solution. These features included file and file metadata management, category management, workflow management, e-mail notification, custom reporting, and user/rolebased security management. Without a pause for breath, I began working on the pilot to demo for the proposal delivery.

Within a week, I had a partially functional demo - built in ColdFusion with a Microsoft SQL Server back end. It highlighted all of the functionality that the system required - albeit not yet present. When it came time to present, our pilot was well received. Although ColdFusion was not yet an accepted platform for development, we were able to convince the client otherwise and managed to win the project. Within a few days, we began development of the custom DAMS.

Now, the client has a robust, scalable DAMS that was built with their needs in mind, and has the flexibility to be modified with ease. Add another notch to ColdFusion's belt!

Enhancements to the CFMAIL Tag
One of the features that this system offers is e-mail notification. This feature is as trivial as it is mission critical. There are several products on the market that provide email list functionality. However, most of these products do not offer the appropriate functionality to integrate seamlessly with the applications that we ColdFusion developers create and have to work with.

Fortunately we have been blessed with the simplicity of the CFMAIL tag, which has solved our e-mail needs. Now, with ColdFusion MX 6.1, we have even greater power to deliver secure e-mail applications with SMTP authentication.

Code I shows an example of the CFMAIL tag with SMTP authentication.

Notice the two new attributes to the CFMAIL tag: username and password. These attributes represent the Username and Password that are required by some mail servers to authenticate before a client can send e-mail messages.

This new feature of the CFMAIL tag has opened up a new door for our DAMS. Until ColdFusion MX 6.1, we were relying on our own mail servers to deliver daily and weekly notifications to the thousands of users of this system. Not only was this a load that we did not want to carry, we had already subscribed to a service that provided SMTP access for other applications that we supported. However, these SMTP servers were open only to authenticated users.

Now that we utilize SMTP authentication, we have been able to streamline our application, and our network, by isolating all e-mail-related functionality to our subscription service.

Behind the Scenes
One of the requirements for the e-mail notification function that the DAMS required was to send daily update e-mails to users of the system with all of the additions and updates made to the system that day. Thus, when an asset is added to or updated in the DAMS, an entry is made within a Notification Queue. This queue is scanned nightly for new entries by a ColdFusion Scheduled Task. If new entries are found, they are purged into a list of new entries. This list of new entries is distributed to the users of the DAMS. Image I outlines this process.

This model would work. However it does not take into consideration this system's security model, which includes user- and role-based access restriction to assets within the DAMS. Therefore, users should not receive a notification about an asset that they do not have access to.

With this in mind, we had to rethink how the Notification Queue worked. The ColdFusion Scheduled Task would have to check if a user had access to a particular asset before the Notification Queue entry could be sent to that user. Image II outlines the revised process.

Now that we have rethought the process, how do we achieve this in code? Simple! Let's start by dissecting the ColdFusion Scheduled Task that actually sends these messages.

The first thing we must do is check the Notification Queue to see if there are any new entries. (see Code II)

If the value of EntryCount from the query above is zero, then we exit the task since there are no entries to purge and send. However, if EntryCount is greater than zero, we must continue with the task as there are new entries in the Notification Queue.

<cfif selNotificationQueue.EntryCount>

Now that we know we must purge the Notification Queue and send an email message to each authorized user, we can begin to build the message.

First, we load in our default header and footer text from text files located on the server whose paths are stored in Request variables in the Application.cfm (see Code III).

Now, we must obtain a list of the users in the system. We do this by querying the Users table (see Code IV).

With our list of users, we can now iterate over them to create a customized e-mail message based on their permissions. To do this, we query the Notification Queue to find entries that the user has access to. We determine whether or not a specific user has access to an entry with a user-defined SQL function that checks the restrictions table for both user and role access (see Code V).

If the query in Code V returns more than one record, then the user has access to one or more new entries in the Notification Queue. Therefore, we must send them an email message (see Code VI).

In Code VI, we begin the construction of our user-specific e-mail message. After setting the subject and the content header, we loop over each entry from the Notification Queue that the user has access to. Then, we complete the content by adding the footer text.

Now we are ready to send the userspecific e-mail message. Once the message has been sent, we continue looping through the list of users, sending each user a custom e-mail message based on their access (see Code VII).

Once we have finished looping over all of the users, we must now update the status of the entries that were sent in this task to Sent, stored in the database as 1. We can use the ValueList() function to obtain a list of the Entry IDs (see Code VIII).

That's it! We have now updated the users of the DAMS with relevant information about only those assets that they have access to.

Conclusion
The enhancements to CFMAIL are just the icing on the cake for ColdFusion MX 6.1. The performance gains I've observed in the applications I've built running this release are astounding, and continue to motivate me to introduce ColdFusion to all of my clients. The Notification Queue dissected in this article is only one of the many robust systems that can be built using CFMAIL. I would encourage you to extend your thoughts beyond e-mail forms and imagine how you can use CFMAIL in new and exciting ways.

• Source Code