Ignify eCommerce is a comprehensive, and highly scalable e-commerce solution that automates the online buying experience with end to end order fulfillment in a single cohesive system. An object oriented and component-based e-commerce software architecture followed in Ignify eCommerce enables you to help your customers easily find desired products, learn about new offerings, comparison shop, register for gifts, redeem coupons, and easily complete their purchases. Its zero touch fulfillment software enables merchants using Microsoft Dynamics ERP or Sage MAS ERPs to have 80% or more orders to go directly to warehouse without any human interaction giving merchants a unique capability to improve customer service while reducing operating cost at the same time.
Out-of-the-box capabilities like self-service order entry, customer service, account administration, and other features also help merchants significantly reduce operating costs. This document details the technical architecture with a solution oriented view to give a perspective of technical architecture to help merchant implementations draw their own solution architecture out of it.
The rest of this document contains details on the Ignify eCommerce Architecture as it pertain to version 4.0 and higher versions
- BUILDING BLOCKS OF IGNIFY ECOMMERCE
There are two basic building blocks followed across eCommerce application - Engines and Frameworks.
Engines are like small intelligent modules designed to do a specific task with efficiency. These are independent modules that take input and generate a specific output. An example is a shipping engine that takes either a shopping cart or an order as an input and generates all available shipping quotations as an output. This shipping engine can be integrated with any other system to provide shipping quotation services. Engines are like eCommerce Service Providers; they are designed to provide various services required by an eCommerce operation.
Frameworks on the other hand are the foundation on which certain sub systems are developed. These frameworks unlike engines by themselves do not do much but they provide base services on top of which one or more sub systems are built. For ex: Metadata Framework allows for an extensible catalog system but by itself the Metadata Framework has no use. Frameworks within eCommerce Systems are designed to provide a foundation to solve various business challenges but they by themselves solve no business challenge.
A listing of various frameworks and engines included within Ignify eCommerce is given below. A detailed explanation follows in deep dive sections.
|Ignify eCommerce Frameworks
||Ignify eCommerce Engines
|Front Store Framework
|Checkout Controller Framework
|Batch Process Framework
|Application Configuration & Security Framework
|Manager Panel Security Framework
||Address Validation Engine
Ignify eCommerce Software is made up of several sub systems. These sub systems are designed for specific users and their business needs. All of these subsystems are architected in a decoupled manner meaning any of these sub systems can be replaced with relative ease in case a merchant has a legacy system that they want to continue with. As an example – A merchant might have an order entry system that they want to continue with but may want to use Ignify eCommerce for the customer facing self service order entry.
Figure 1 – Payment Process Communication Log
Ignify eCommerce Solution Stack comprises sub systems that are required at run time. This document focuses on sub systems required by run time. Sub Systems required during development, deployment and data migration are not within the scope of current document.
Given below is a list of run time sub systems within Ignify eCommerce.
- Catalog & Content Sub Systems
- Checkout Sub System
- Order Entry & Management Sub System
- Customer Profile Sub System
- ERP Integration Sub System
- Reporting Sub System
- CATALOG & CONTENT SUB SYSTEMS
Catalog & Content Sub System is built on a Meta Data Framework and Catalog Framework. Meta Data Framework allows Catalog to be defined as per product lines carried by a merchant. Products in different product lines can be classified in different Product Classes having different attributes defined by Meta Data Framework. For ex: A bag might have two attributes such as “Inside Dimension” and “Outside Dimension” while a shirt might have a dimension “Size”. Meta Data Framework allows such custom attributes to be created for different lines of products. The rendering of such products is controlled by templates that are custom ASP.NET controls built to render custom fields.
Catalog Framework includes Category, Product and SKU as basic entities. Separation of Product and SKU allows for all content to be attached to the product while SKUs are the actual items that buyers purchase. Category offers arranging the catalog in any manner required. One product can be associated with multiple categories as needed.
The final element in the Catalog & Content sub system is a Front Store Framework that allows - laying out the web pages, skinning web pages and a library of standard widgets that can be used to build the web pages. Web Page Layout and Skin is fully driven using standard CSS allowing web designers to layout the catalog in any manner required once right widgets are dropped on the page. Front End Framework has Jquery and YUI integrated with the pages for web page designers to use if needed. There are a number of standard widgets (built in the form of ASP.NET Custom Control) present in Ignify eCommerce Library that can be dropped on the catalog web pages as per business needed before layout and skinning is taken up. While dropping the controls on the page requires web page code to be modified (for inclusion of required control), the layout and skin can be fully managed with just CSS changes. Standard Widgets contain content blocks for full page or part of the page, these content blocks can be used for adding any content on store front.
The front store framework combined with meta data framework allows an easily extensible framework for publishing merchandise related content as well as other content on the store front web site. Depending on Product Lines and Content Type specific classes can be created that can then be rendered using built in or custom templates on the front store.
Figure 2 – Catalog Sub System Architecture
Catalog Subsystem includes Front Store Catalog that is presented to buyers, a Catalog Manager that is used by Store Manager to manage the catalog and an Integration Module to integrate Catalog System with various ERPs.
- CATALOG FRONT END
Catalog Front End is made up of out of box store front web pages (ASP.NET), custom control libraries (ASCX files), three layout and three skins to choose from. The front end includes a fully working eCommerce store front with a My Account and Checkout section.
- ASP.NET PAGE CACHING
ASP.NET Page or Fragment caching is enabled in the entire front store to cache web pages or fragments that do not change on regular basis. This allows the store front to be more scalable by reducing the load on the database.
- CATALOG CLIENT LIBRARY
Client Library is a set of .NET components that acts as the bridge between front end catalog and back end. Client Library internally makes a call to various engines such as Navigation, Search and Merchandising engines.
- CATALOG APPLICATION
Catalog application includes several engines as explained below:
- Search Engine – Ignify eCommerce Search Engine is built upon SQL Server 2005 Full Text Search Technology. The search engine is enhanced for personalization to return a personalized catalog as well as custom terms that includes misspellings or synonyms that may not be part of product description. It is possible to configure what fields within catalog tables should be indexed an searched by the search engine.
- Merchandising Engine – Queries such as “People who bought this also bought”, “Related Products” and “Accessories” are serviced by Merchandising Engine. Both automated as well as manually configurable options are available within Merchandising Engine giving a lot of flexibility to merchants to showcase their merchandise.
- Promotions/Discount Engine – Promotions engine calculates manuals and automated discounts and shows them on the front store catalog. The same engine is responsible for applying discounts on the shopping cart.
- Pricing Engine – Pricing Engine returns Unit Price for each SKU. The pricing engine has the capability to match pricing as per various ERPs that Ignify eCommerce works with. Prices in eCommerce would match as configured in various ERPs. To decouple eCommerce with ERP system, Ignify has re-implemented pricing engines as defined by various ERPs. This not only ensures decoupling of ERP from eCommerce but it also provides for higher performance.
- APPLICATION CACHING
Catalog sub system internally caches meta data framework and certain elements of catalog framework when the system starts. This is done to reduce the load on the database. If front store page level caching is in use, then it is recommended to turn off this caching. This cache is useful only when page level caching is not in use. For example – Personalized Catalog for each Customer cannot use page level caching, there application caching would be useful.
- DATABASE ACCESS OBJECTS
eCommerce Catalog has a well separated data layer that is integrated with SQL Server 2005. Though the layer is designed to be database agnostic there are features such as search engine that use SQL Server specific technology.
- CATALOG IMPORT MANAGER
Within eCommerce Manager Panel, there is an application for importing and exporting the catalog category, products and SKUs from or to Microsoft Excel. Import Manager uses client library to read or write from catalog sub system.
These include Catalog, Price and Inventory Quantity Integrations from various ERPs. These integrations are configurable to work with various ERPs supported by Ignify eCommerce. All Integrations are done via web services over a secured HTTPS channel. The integrations have a direct database API in the form of stored procedures since for both Pricing and Quantity these are simple one way – ERP to eCommerce - database updates.
- CHECKOUT SUB SYSTEM
Checkout Sub System is built upon Checkout Controller Framework. This framework is similar to a metadata framework that allows a merchant to add custom fields in the checkout process. In addition it provides for a page processor framework where a page can be submitted to the controller with one or more fields on the page, page processor then determines what has to be done with the page based on the page content. For example: if a coupon field is passed then the page processor would call promotion engine to process coupon field and calculate discounts based on submitted coupon.
Such a framework gives a lot of flexibility to developers while designing checkout process. Merchants can choose between popular single page checkout as well as a variety of other multi step checkout processes as suitable to their business needs. Addition of fields in the checkout process is extremely simple if these fields just require storage of additional data, in case the field decides the checkout processing then this can be obtained by customizing the web page (for click through customizations) or extending the controller framework to write logic for processing custom fields. One example of such a customization is a check for age of 18 years or more for checkout process required by an arms and ammunition merchant.
Figure 3 – Architecture of Checkout Sub System
Checkout Sub System includes front store checkout process as well as capability for a store manager to setup various options such as shipping methods, tax and discounts. eCommerce Manager provides facility to add or edit these options. These are then picked up by various engines.
FRONT STORE FRAMEWORK
Front Store Framework used by checkout sub system is the same framework used by Catalog Sub System with one difference. The standard widgets offered by checkout sub systems are “web pages” and not “custom controls”. The reason for using pages instead of controls is to support page processor that processes all fields present on a checkout page. Ignify eCommerce offers two checkout processes out of box – one page checkout and a multi step checkout.
SHOPPING CART CONTROL AND SHOPPING CART
Shopping Cart ASCX Control is a special user control used for rendering the shopping cart in a friendly manner. This control also allows for editing the shopping cart as needed. The Shopping Cart itself is maintained as an XML file having nodes for Cart Header as well as Lines. Same XML can be used for integrating orders from any third party system. Shopping Cart component converts this XML into a real eCommerce Order by passing it on to Ordering Sub System.
Checkout Sub System includes several engines as explained below:
- Shipping Engine – eCommerce Shipping Engine is designed to work with multiple carriers as well as multiple source and destination addresses and provide a shipping quotation. Shipping Engine divides a shopping cart or an order into multiple carts internally based on source and destination addresses. If a merchant ships from two warehouses and there are two cart lines getting shipped to a single address but from two warehouses, then two carts would be internally created by Shipping Engine for getting real time quotations from various carriers. Shipping Engine internally launches multiple threads for each carrier and cart. In case Fedex and UPS quotations are required in above case, then 4 threads would be launched for getting quotes. This means quotes are obtained in the same amount of time as taken by a single cart and single carrier.
- Tax Engine – eCommerce Tax Engine uses a provider pattern where the engine can use the internal tax engine provided by Ignify or use an external tax engine such as Avalara for tax calculation. Internal Tax Engine uses Ignify Catalog System, internal tax tables along with shipping address to calculate taxes. Internal Tax Engine also services taxable freight. The tax engine has rounding rules that can match with the ERP system to ensure that tax computation in ERP system and eCommerce system can be identical.
- Promotion Engine – Promotion Engine described in Catalog Sub System is also used here to apply discounts on shopping cart lines.
- Payment Engine – Payment Engine is used by Page Processor to process the payment during checkout.
- For Credit Card Payments, payment engine would authorize the credit card.
- For ACH payments, it would submit the ACH to the bank.
- For Paypal payments, it would redirect to Paypal web site for Paypal Authorization.
- For other payment methods such as Terms, the engine would call internal Ignify eCommerce Payment processors.
Checkout Sub System supports alternate checkout methods such as Paypal Checkout and Google Checkout using plug ins. The plug ins follow the checkout process as defined by third party providers and eventually convert the entire shopping cart to Ignify shopping cart format to help place an order using standard Ordering Sub System. This allows Checkout Sub System to accept orders from various checkout systems and still maintain a standard Order Schema.
- PROFILE SUB SYSTEM
User Profile Sub System in Ignify eCommerce is exclusively used by Buyers purchasing on the store front. CSRs or Store Managers have a separate profile system which is a part of security framework. Profile Sub System is a full fledged implementation of ASP.NET membership provider and permits usage of the authentication and membership controls provided with ASP.NET. Profile Sub System also includes a web service for creating or updating profiles, this facility is utilized by ERP Integrations to update eCommerce profiles based on ERP Customer Master.
The profiles system has support for encryption including both one-way hashing for secure storage of passwords and asymmetric encryption for secure storage of sensitive data such as credit cards. The Key Manager tool is a WinForms tool offered with Ignify Utilities that can be used to generate new encryption keys and store them securely. It also supports rolling the encryption keys and re-encrypting profile data with a new key.
Profile Sub System is designed to handle three different roles – Guest, Registered Customer and Sub Customer. Sub Customers are multiple users under a single Customer Account.
Figure 4 – Architecture of Profile Sub System
- CUSTOMER ACCOUNT ASP.NET PAGES
These pages and controls create “My Account” section on the front store. These pages and controls follow the same Front Store Framework explained in Catalog Sub System. There are a number of standard widgets provided for Profile Services such as “Order History”, “Address Book” and “CC Wallet” etc. A merchant may choose these widgets as needed to create a powerful self service My Account section of the store front.
- PROFILE OBJECT
Standard ASP.NET Membership objects are available across the entire front store to allow specific store front areas to be seen by Guest, Customer or Sub Customers as needed. Profile object is also used for offering personalized catalog.
- CUSTOMER PROFILE APPLICATION
This application comprises .NET API to manage various profile entities such as Address Book etc. Same application enables customer registration on front store. The registration is configurable to auto approve or manually approve registrations. The Profile Application is designed to handle Customer Numbering and Address Naming conventions as require by various ERP systems.
- CUSTOMER DTO
Customer Data Transfer Objects are designed to act as a data abstraction layer and keep the business logic independent of the database schema. These interact with underlying SQL Server 2005 database.
- CUSTOMER, ADDRESS AND SUB USER MANAGEMENT
Customer Management Interface used by CSRs is a part of Manager Panel. The management interface is a set of web pages that allows CSRs to view or edit Customer and Address Information. There is a role based security framework that allows merchants to control which CSRs can access Customer Management, Catalog Management and Order Management.
- CUSTOMER ACCOUNT AND ADDRESS WEB SERVICES
These web services have the capabilities to import as well as export Account and Address details. The services during import of data expect a translated set of data – meaning all fields should have values as expected by Profile Sub System. Any data translation or mapping has to be done before the web service is invoked else the service would throw a validation error.
- CUSTOMER VIEWS
Export of Customer Account and Address information is supported via Database Views. These views offer a standard ERP Friendly view of Profile Data. Some level of mapping modifications can be done here. As an example: if an ERP system has 2 address lines while eCommerce has 3 address lines, you can combine eCommerce address line 2 and 3 to generate ERP address line 2 provided the field length allows this to be done.
- ORDER ENTRY AND MANAGEMENT SUB SYSTEM
The Ignify eCommerce Order Management framework is designed to be a highly scalable and user friendly order entry and management system. Order Management includes a support services module that uses the same engines used by Checkout Sub System offering a consistent business rules environment for Orders within Ignify eCommerce.
Order Entry is designed to have capabilities to accept a large number of orders within a short span of time. The design is geared to handle spikes in volumes that might happen due to a promotion or a stock sale situation. Ordering Application uses highly optimized engines for hold and fraud checks as well as Order Edits.
Figure 5 – Architecture of Order Entry & Management Sub System
Order Entry and Management includes a bunch of support services, front store ordering capabilities, a robust Order Management System, Order Integration to ERPs and a Invoice Integration module to handle Order Fulfillment. Ignify eCommerce's order management sub-system ties natively into the core fulfillment facilities provided by the Microsoft Dynamics and Sage MAS ERP systems. Fulfillment Services include inventory allocation, picking, packing and shipment along with updates on general ledger in the ERP system.
- SUPPORT SERVICES
Ordering Support Services include various engines responsible for order calculation, validation and payment authorizations. The engines used here are same as used by Checkout Sub System. All the engines are called via a web service layer.
- FRONT STORE ORDERING
This is supported by Shopping Cart and Order Entities. During the order placement the Shopping Cart passes Cart XML along with an authorized payment to Order Sub System. “Authorized Payment” is accepted after making checks on the legitimacy of the request to avoid any attempts to hack for placing rogue orders. These checks include request validation by verifying Host Name, IP Address an Session Sanctity. If the authorization is found to be legitimate then the system accepts the order by invoking the Ordering Application for accepting the order. At this point, the system generates an order number and commits the order into the system.
- ORDERING APPLICATION
Ordering Application is a set of .NET Entity Classes that are designed to do a set of validations and saving the order. Order Save is performed in a SQL transaction scope, so there is a certain amount of locking of records that happens during order placement. Optimistic Concurrency model has been used to avoid lock escalations.
This application includes auto fraud and auto hold engines that support zero touch fulfillment experience for the merchant. These engines process the order through a set of configurable rules to determine if the order should be placed on “simple hold” or “fraud hold”. If the orders are placed on hold then these orders have to be manually removed from hold before they would be picked up by fulfillment system ie ERP.
- ORDER ENTRY AND MANAGEMENT INTERFACE
Within Manager Panel the Order Entry and Management is a set of web pages laid out in a CSR friendly way to enter new orders and also manage existing orders. The Order Management System recalculates Order Taxes, Shipping and Discounts every time a line is edited. Same engines that are used in front store are used by manager panel via a web service interface. Order Management is integrated with Manager Panel Role Based Security to allow restricted access if required by the merchant.
- ORDER INTEGRATION WEB SERVICES & ORDER TRANSLATION ENGINE
Integration Web Service is responsible for Importing and Exporting Sales Orders. When these sales orders are integrated to ERP systems, there are two business requirements of mapping fields and translating field values. The translation requirement is fulfilled by Translation Engines. Translation engine performs the function of translating value of a particular field to specific ERP requirement. For example: “UPS Ground” shipping method in eCommerce might be called as “UPSG” in ERP.
- INVOICE INTEGRATION WEB SERVICES
Order Management Sub System uses ERP as the fulfillment system. Presence of an invoice against an order indicates to Order Management Sub System that one or more order lines have been fulfilled. These invoices are directly integrated in eCommerce Database using Invoice Integration Database Objects.
- ERP INTEGRATION SUB SYSTEM
Ignify eCommerce integration sub system works with a number of ERP systems out of box. This sub system uses a Winforms base integration framework – a lightweight framework designed to take care of batching of processes, error handling and generating detailed logs for troubleshooting in case a transaction gets stuck.
The framework also includes a generic Winforms User Interface that can be used for configuration of specific entities as well as running the integrations manually.
Figure 6 – Architecture of Integration Sub System
Integration Sub System is made up of eCommerce web services that are explained earlier in individual sub systems, WinForms based Integration Framework, record queues and ERP specific engines responsible for taking care of business logic embedded in each ERP system.
- RECORD QUEUES
Integration sub system is designed to batch process records that are held in a queue waiting to be processed. These queues are maintained within the source system that generates the records. In ERP system these queues are generated by database triggers, these triggers have been highly optimized to avoid impacting regular ERP operations. The queues are nothing else but simple tables holding records of each type. While a record is added in the queue by specific ERP or eCommerce operation, the records are removed only by a successful integration or manual intervention.
- INTEGRATION LOGGER AND SCHEDULER
These two components are part of Integration Framework and as the name suggests they are used to schedule the integrations and log the results. There is one key task that integration logger does which is important to understand, it removes the record from the queue once a successful integration is done.
- DATA TRANSLATION ENGINES
These engines are responsible for translating field values as integrations run. The values are translated both ways ie from ERP to eCom and vice versa. In most of the cases these translations are mentioned as an additional column in the master tables.
- ECOMMERCE TO ERP INTEGRATIONS
These are .NET modules responsible for actually integrating records with a WinForms User Interfaces as well as Batch Process Interface meant for specific integrations where data source is eCommerce and target is ERP.
- ERP TO ECOMMERCE INTEGRATIONS
These are .NET modules responsible for actually integrating records with a WinForms Process User Interfaces meant for specific integrations but with reverse flow – source is ERP and target is eCommerce. There are also process flows within these integrations. For example: An invoice for a specific order can be integrated only after that order is successfully integrated.
- ERP ENGINES
The engines are .NET assemblies designed separately for each ERP and each version. The engines have the intelligence to understand how transactions are carried out and how master data is maintained within each ERP. The engines are responsible for mapping fields and processing data if required to fit into specific fields. For example, in Dynamics AX Shipping Charges have to be sent as miscellaneous fee. Dynamics AX Engines have this knowledge to map the fields appropriately. The out of box field mappings work with standard eCommerce and standard ERP across all versions and all supported transactions.
- INTEGRATION OBJECTS
These objects are responsible for creating a specific record in the ERP. The objective behind having these integration objects to reuse the business logic already built into the ERP. In many cases merchants have customized order entry in their ERP system, these objects make it possible for Integration Sub System to reuse that logic by customizing integration objects. These objects are written in proprietary languages followed by each sub system and T SQL.