xWeb: netFORUM Overview

netFORUM is an enterprise-wide, Web-based system that includes association management (AMS), marketing, eCommerce, and content management capabilities. To run netFORUM, users simply need a browser on their machine. netFORUM is built using Microsoft's .NET.

netFORUM is an all-web system and is deployed as two primary web interfaces - iWeb for internal staff users and eWeb for external users such as members and prospects. iWeb provides standard association management capabilities such as membership management, event management and inventory control. eWeb can run your corporate web site, provide member self service and deliver eCommerce capabilities to your external stake holders.

netFORUM Toolkit

The engine that powers netFORUM is the Toolkit. The Toolkit allows organizations to easily add new fields, screens, and business processes - all while remaining on a supportable, upgradeable baseline system.

The Toolkit consists of a security manager, Deploy Tool, Form Designer and overall development tool to build new functions and processes. The Toolkit does not require programming to use so it is an extremely rapid development environment.

Because iWeb and eWeb were built with the Toolkit, virtually the entire enterprise system can be modified and enhanced with the Toolkit. This provides organizations extensive capabilities to support their future needs.

netFORUM iWeb

The netFORUM iWeb is the internal enterprise system for membership organizations to run their entire operation. This system provides new internet tools such as on-line communications, campaign tracking and on-line reports. It also provides all the standard functions of a membership system - membership management, event management, exhibit management, financial and inventory management, fundraising, grants management and certification and accreditation management.

netFORUM eWeb

The netFORUM eWeb system is the external public web site. It is primarily a content management system (CMS) but also has tools to deploy capabilities that exist in the iWeb. In addition to the CMS, eWeb also provides eCommerce capabilities for product purchase and on-line event registration. It has member self-service and on-line directories, surveys, committees and chapter access, job bank and discussion groups.

netFORUM xWeb

netFORUM xWeb is an integration toolkit for external third party programs to interface to the netFORUM database. The xWeb integration tool is the primary topic for this document.

netFORUM uses XML to interface between itself and other systems. Essentially all objects (collections of data) in netFORUM can be accessed via XML; this includes selected data as well as updates, inserts and soft-deletes. Information from both the internal system (iWeb) - demographic data and buying history, as well as data from the external system (eWeb) -- web site usage and page hits, can be extracted from the system.

netFORUM Data

netFORUM is a distributed application. Each instance of netFORUM has an different set of data, although the schema of the core system is the mostly the same but can vary.

Schema Variations

The schema of netFORUM Types is auto-generated from the underlying database of each netFORUM instance. The netFORUM database contains more than 10,000 columns in 800+ database tables. Every client will have every baseline table and column. Every client will also have a handful of custom extender columns in various extender tables, most commonly the tables for Individual, Organization and Customer. This means that all netFORUM sites are at least 99.5 percent similar. Extender Columns contain specialized client data and are unique to each netFORUM site. If one client has an extender column of a particular name, it is highly unlikely that any other netFORUM client will have an extender column of the same name.

Additionally most netFORUM clients will have additional custom tables; you will rarely see these tables references in schema and they are generally accessed via GetQuery, InsertFacadeObject and UpdateFacadeObject.

How does this translate into differences in schema? Take the co_individual table, for instance. That table is the core of many schema elements for individuals, such as the IndividualType which has an element called Individual of a type called Individual_Individual_DataObjectType.

The Individual_Individual_DataObjectType type contains many elements for the different fields of an individual. Both baseline fields and extender columns are contained in this type. Extender columns are no different than baseline columns; the only way you can tell them apart is that extender columns end with _ext.

Here is a portion of the schema for Individual Type:

<s:complexType name="IndividualType">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="CurrentKey" nillable="true" type="tns:av_key_Type">
<s:annotation>
<s:documentation>Primary Key.The current key is the record key for the object. This field must be set whenever updating an existing database record.</s:documentation>
</s:annotation>
</s:element>
<s:element name="Individual" type="tns:Individual_Individual_DataObjectType" />
<s:element name="Customer" type="tns:Individual_Customer_DataObjectType" />
<s:element name="Address_Change_Log" type="tns:Individual_Address_Change_Log_DataObjectType" />
<!-- other similar elements omitted for brevity -->
</s:sequence>
</s:complexType>

Generally, every netFORUM client will have the exact same elements for these types, with the exact same DataObject elements. Where you may see some variations is that within each DataObject element you may have additional elements for custom extender columns.

In some rare cases, a type like IndividualType may have additional DataObject elements although this is uncommon. These additional elements should not be required and if you have an application that is used my multiple netFORUM clients, you can probably safely disregard/ignore such an additional element.

Here is a shortened clip from the Individual_Individual_DataObjectType element showing two elements representing columns. The first (ind_cst_key) is a baseline column and the second (int_testimony_ext) is an extender column:

<s:complexType name="Individual_Individual_DataObjectType">
<s:sequence>
<!-- other elements removed for brevity -->
<s:element minOccurs="0" maxOccurs="1" name="ind_cst_key" nillable="true" type="tns:av_key_Type">
<s:annotation>
<s:documentation>Primary Key.</s:documentation>
</s:annotation>
</s:element>
<s:element minOccurs="0" maxOccurs="1" name="ind_testimony_ext" nillable="true" type="tns:av_text_Type">
<s:annotation>
<s:documentation>Testimony.</s:documentation>
</s:annotation>
</s:element>
</s:sequence>
</s:complexType>

For a client with extender columns, each additional extender column will appear in the schema as additional elements. These additional elements will always have the minOccurs value of 0 and maxOccurs value of 1, meaning that you can omit these elements from your requests. If you're trying to build an application that will be used by multiple netFORUM clients, you generally won't need to account for extender columns since they aren't required to be included in requests and they can be ignored in responses. Think of extender columns as optional additional elements for base DataObject elements.

Just as schema can vary from one client to the next, schema will also vary from one release of netFORUM to the next as explained in xWeb Build.

Data Variations

Be aware that although many clients run netFORUM, each client will have different setup data with different primary keys (which are often used as parameters for different web methods). Take Address Types for example. Address Types can be Home, Work, Shipping, Billing, etc. The list of these values can be different for every netFORUM instance. Don't assume that every client has a "Home" address type, and if they do, they will NOT be the same primary key. For performance purposes, your application might want to cache the list of address types as this list will rarely if ever change in a mature system, but they will be different for each netFORUM instance.

The same rule applies to prefixes, suffixes and other Lookup tables.

Therefore, if you're building an application that you intend to be used in more than one netFORUM instance, ensure that you do not hard-code setup values that you might (incorrectly) presume will be universal to every netFORUM instance. There might be some relatively static data (such as Gift Types) that you might want to reference in your application with a constant, but if so allow each client a setup console where they can configure the value of that constant to match with their own unique netFORUM data.