Overview
Blackbaud NetCommunity provides an open programmable architecture for incorporating powerful customizations into the product. Via Custom Parts, Custom Web Services, and Custom Transactions, a vast array of rich web site enhancements can be created to provide unique solutions to individual clients. These enhancements surface throughout the system in such a way as to provide a transparent integration between what is built in to the solution and what is custom.
With Custom Parts, new features and types of content can be added to your web site. With Custom Services, web service access to your back office data is made available, and with Custom Transactions, data captured in your custom parts can be processed by the back office. The possible application of these features is bound only by one’s imagination.
This article outlines the NetCommunity Platform's Extensibility Model and is intended for anyone interested in understanding the scope of what’s possible, what’s not possible, and what’s involved in taking advantage of this powerful capability. For the first section of this article, it is assumed that the reader has a basic understanding of Blackbaud NetCommunity from a site designer’s perspective. To understand the building of NetCommunity customizations it is assumed that the reader has a moderate working technical knowledge of ASP.NET.
Understanding the Platform
Blackbaud NetCommunity has been created using Microsoft.NET technology. This has significance in a number of positive ways.
First of all, the content management system is built using ASP.NET, leveraging the Web User Control concept to construct pages composed of distinct reusable page components, or parts. In fact, each one of Blackbaud NetCommunity’s Parts is implemented as a web user control. Simply put, if you can create a .NET user control for the part you want, it can live nicely in and be managed by Blackbaud NetCommunity. Any developer with a moderate level of experience developing ASP.NET applications should be comfortable building custom parts.
Pages are built on demand from content stored in the Blackbaud NetCommunity SQL Server database. But that doesn’t mean you can’t pull content data from other places. The Newsreader part, for example pulls RSS feeds (Blogs) from other sites. But, at the same time stores its design-time settings (e.g. which blog to show) in the Blackbaud NetCommunity database. By the same token, several parts show data pulled from The Raiser’s Edge.
Secondly, Blackbaud NetCommunity is built upon a Service Oriented Architecture, meaning that data is delivered between the various components of the solution via .NET Web Services.
Access to The Raiser’s Edge data from Blackbaud NetCommunity and access to web transaction data (e.g. donations, profile updates, etc.) from within The Raiser’s Edge is managed across two built-in web services. The use of web service technology provides for data access across the Internet using firewall-safe protocols such as HTTP and HTTPS, allowing Blackbaud NetCommunity web sites to be hosted in different locations than the back office, if desired.
The figure below illustrates how the components of the Blackbaud NetCommunity solution come together to form a pipeline connecting web content and back office data. This full circle model facilitates the displaying and/or editing of back office data on the web as well as the downloading of data modified on the web (transactions) to the back office.
Opening the Architecture
At key points along this pipeline, Blackbaud NetCommunity provides open access to the developer. With a moderate level of ASP.NET programming experience, a developer can:
- Create Custom Parts – and install them to the system where they show up and are content-managed just like the built-in parts. Custom parts can do anything a .NET web user control can do, displaying HTML-based content, forms, and even information from other systems. Custom parts surface in all of the content management features, such as the page designer, role based security for targeting content, and scheduled publishing. To the system, they are no different from the built-in parts that ship with the product.
- Create Custom Web Service Methods – and install them to the system where they can easily be called by your custom parts. These custom web methods reside in back office data retrieval web service – meaning they will have direct access to the back office systems via their respective APIs. For example, a web method could be written to retrieve a constituent’s volunteer information from the Raiser’s Edge, via the Raiser’s Edge API. Then, a custom part could be written to utilize this service to show a constituent her volunteer information and allow her to update it. By utilizing the existing pipeline, the developer does not need to build his own web service. Furthermore, the extensibility layer hides the details of calling the web service from the developer, freeing the developer from the mechanics and deployment details, to focus solely on what data to retrieve. Additionally, the APIs to access the Blackbaud systems (RE, FE, and EE) are included and instantiated as part of the platform (assuming you have installations of those products).
- Create Custom Transactions - via the Blackbaud NetCommunity API, the developer can define new transaction types and record any number of transactions of that type. Transactions can contain any variety of data captured in web forms on custom parts. For example, you may want to offer a Contact Me form on your web site, where someone can fill out a short form with name, phone, and email address in the hopes of being contacted. The Blackbaud NetCommunity API provides an easy to use interface for defining and recording custom transactions from your custom parts. Again, the developer is shielded from the mechanics, free to focus solely on what data to capture from the user.
- Process Custom Transactions – as you accumulate custom transactions you will likely need to process them. The same pipeline that delivers donations, event registrations, and all of the other built-in transactions to The Raiser’s Edge, has been opened to allow you to deliver your custom transactions to your own custom code that you install to the back office system, much like a classic Raiser's
Edge plugin. Your custom transactions are displayed in the NetCommunity module of Raiser's Edge along side the built-in ones, where your custom processing can utilize Raiser’s Edge APIs to take the appropriate action with the data, such as updating a constituent's record or recording a constituent Action.
What do we mean by Back Office?
It is important to point out that the Data Retrieval Web Service pipeline to the back office system is not solely for retrieving data from The Raiser’s Edge. While, the web service is actually named the RE7Service, think of it more as a conduit to retrieve any data from the back office. This can include The Financial Edge, The Education Edge, or any other application you have data access to. The web service simply provides an already installed mechanism to travel the Internet to get the data from systems on your internal network, and the custom method framework provides an easily plugable model for adding your own methods to the service. As a programming convenience, the RE7Service will provide you with RE/FE/EE API Session Context objects for your connected systems, if present.
Putting it all together
There are a vast number of possibile uses for the NetCommunity Platform APIs and there are many degrees of complexity that can be supported within the customizations. The best way to get started is to walk through a simple sample custom part to get a feel for how to begin, and then gradually build upon that sample to demonstrate the depth of possibilities. The Getting Started Samples that are included on this web site take this approach and we encourage you to explore, give it a try, and let your mind consider the art of the possible.