Important Notice from AspDotNetStorefront
It is with dismay that we report that we have been forced, through the action of hackers, to shut off write-access to this forum. We are keen to leave the wealth of material available to you for research. We have opened a new forum from which our community of users can seek help, support and advice from us and from each other. To post a new question to our community, please visit: http://forums.vortx.com
Results 1 to 3 of 3

Thread: ML ERPS Integration Specification

  1. #1
    Rob is offline Senior Member
    Join Date
    Aug 2004
    Posts
    3,037

    Default ML ERPS Integration Specification

    {This is a placeholder thread and will be expanded on shortly}

    We now have a draft v1.0 ERPS integration specification, which shows how ML v8.0 can integrate with many back-office systems, including ERP, CRM, POS, Fulfillment, Order mgmt, etc...the doc is a developers reference. Contact Sales for more information. As the specification gets further, we'll post the ref here, or in the manual or both.

    Synopis:

    ERPS Introduction

    1.1. Overview and Scope

    This specification covers the ERP Provider Sync Specification (ERPS) v1.0 for integrating AspDotNetStorefront ML v8.1 or higher with external ERP systems.

    NOTE: This spec also refers to, and relies on our Web Service Automation Interface (WSI) specification. Portions of this specification (e.g. WSI) are implemented in ML v8.0.

    The ERPS is defined with the objective of allowing real-time, near real-time, and batch sync with external master ERP systems, to allow control of AspDotNetStorefront (ASPDNSF) enabled e-commerce sites.

    In this specification, the ERP system is considered to be the “master” data source and ASPDNSF to be the “slave”.

    NOTE: Our OEM partner http://www.channeladvisor.com, which OEM's our ML platform to power it's premium storefront offering, has already achieved nearly total seamless sync with this interface. Channel advisor specializes in push to auction multi-channel commerce services. This shows how ML platform can be connected to other external systems. Stone Edge Order Manager integration will be posted shortly.

    1.2. Objectives

    In an ideal sense, the objective of this specification is to allow ERP systems and ASPDNSF to be fully integrated in real-time, near real-time, or batch mode with a master ERP management system.

    At a high level conceptually, the ERP master provides (and updates) all manufacturer, category (entity), product, price, inventory and other similar data to the ASPDNSF slave. Newly created Customers and Orders in ASPDNSF are sent to the ERP master for fulfillment, handling and processing also.

    In an ideal implementation, the existing ASPDNSF “admin site” (merchant control panel) would not even have to be used to fully control the ASPDNSF website. That objective is beyond the scope of ERPS v1.0 specification however.

    NOTE: in particular, if they wanted to start with an "empty" storefront using in-process providers only.

    A likely implementation scenario will use WSI push for bulk data population, supported by real-time (or very near real-time) in-process providers for highly dynamic, and typically incremental, data updates (e.g. push ERP catalog from master using WSI, but provide in-process provider for real-time price and inventory status).

    1.3. Operational Modes and Definitions

    ERPS should support external synchronization with:

    a) External Subsystems, typically used for push and batch type update via WSI, and

    b) In Process Pluggable Components, for maximum real-time pull on demand data during web page load and execution. Note the in-process provider as nearly full acess to the ASPDNSF application, server, web page, and db state, allowing a number of techniques to be utilized

    Data directional modes include both:

    a) Push Provider: injecting data from ERP system into ASPDNSF, typically implemented along with event listeners, and

    b) Pull Provider: ASPDNSF pulls data on demand, typically using in-process pluggable component

    Typically, push mode will be used when batch updating ASPDNSF data from the master ERP system, either in real-time as it’s changed in ERP or through a timed or batch period bulk update. Typically push mode will run through our Web Service Automation Interface (WSI, see separate spec). Typically pull mode will be made as ASPDNSF makes real-time calls to in-process plug-in providers. Note that pull mode doesn’t have to be real-time, it could also include in-process (and even in database) caches that the pluggable provider does to maximize performance, and minimize latency on calls to the master ERP system.

    Figure 1: Integration Model Diagram

    {see below}

    Synch Types supported include:

    a) Batch: this typically is to be used when master ERP system makes bulk WSI calls to update ASPDSF data

    b) Near Real-Time: typically used when the ERP system schedules either batch push updates to ASPDNSF or the pluggable in-process component provider implements caching or other times internal updates, simulating near real-time caching of master ERP data, available for maximum performance by ASPDNSF, and

    c) Real-Time: this typically we be either a push on save in ERP direct to ASPDNSF (possibly also triggering ASPDNSF internal cache flush or update, either in part or total), and/or pull calls from ASPDNSF to a highly tuned in process provider, making efficient calls to the master ERP system for instant data.

    We also assume at this time, that no db schema changes are planned, or anticipated in ASPDNSF. This may mean that the ERPS providers have to do some data shaping or conversion to match the internal ASPDNSF data structures.

    1.4. Performance Considerations

    Our internal goal is to complete website construction (base page) in 50ms or less. This scales well given proper hardware on high traffic sites, and provides crisp page response. The initial page construction involves whatever server side is needed to completely send HTML back to browser on initial request. This then allows the browser to start queuing the external files (images, js files, external css, flash, etc) so that the full page load can be given in 1-2s maximum.

    Given this stringent demand on website page loads for maximum performance, considerations are made in all cases to allow the provider to tune the sync mode in each integration point to match goals of website performance. This usually does mean however that sacrifices are often made in architectures (such as ERPS) to fully prioritize performance over the most “ideal” API (or subsystem) architecture, as all communications with external subsystems involves latency, which can be quite substantial, as multiple ERPS calls will typically be done multiple times on EACH page load of the website.

    We would also expect that some websites would run with near real-time data, and others may run with full real-time data, allowing flexibility to merchant business requirements.

    Additionally, different data sets could be synced differently. E.g. inventory checks may be real-time, and product definition (description, SKU, image, name, price, etc) updates are done in near real-time modes.

    The concurrent use of different sync modes by data is supported.

    We also assume, for simplicity in this specification, that the ERP system is “nearby” to the ASPDNSF website (actually the ASPDNSF SQL database), for minimum latency on communications. Provisions are made using batch, near real-time, and via caching, to allow for slower connections. Those details typically are involved in implementation of the ERPS providers, and are covered only briefly in this specification.

    1.5. Supported Data

    ERPS should support control of the following data:

    • Manufacturers
    • Categories (entities)
    • Products
    • Variants
    • Pricing
    • Inventory
    • Images
    • Shipping Rules (e.g. shipping provider)
    • Tax Rules (e.g. tax provider)
    • Payment Provider (e.g. pluggable gateway, providing auth, capture, void, refund, etc)
    • Customers
    • Orders

    1.6. Reconciling Dirty/Out of Sync Data

    AspDotNetStorefront will make the assumption that, whenever data becomes out of sync, the ERP system will control the master data set. Because of the critical nature of ERP System data, the ERP system will make the final determination as to what happens to irreconcilable changes made via the AspDotNetStorefront website. For example, an account representative may make updates to an order record in the ERP system (such as voiding an order placed by a customer via the website). Should for some reason the call to the website fail to update the order state, one would not desire that AspDotNetStorefront “re-open” the voided order. Therefore, during any synchronization process, the order state (using our previous example) would be set to a voided state based on data received from the ERP system.

    1.7. Size and Scaling


    Primary consideration for size and scaling would be the efficiency and design of the data sent to be consumed by AspDotNetStorefront, specifically in cases of bulk updating large numbers of objects from the ERP system. For scalability, systems integrators should consider failure scenarios when writing code to determine how those scenarios would be handled and later reconciled. For example, it would be ill-advised when using WSI to build a document that contains 100,000 nodes and try to process those all at once where a failure might occur at 99% completion. Instead, it is advised break the transactions into small batches where the chance of failure of would be exponentially smaller, and the subsequent rollback and resubmission would put far less load on both systems.

    1.8. Stateless

    We also assume, in nearly all cases, that each and every call, to a web page is completely stateless, as properly defined with web protocols. We do cache ASPDNSF application state in some cases, but that is ONLY done for performance, and with proper access protocols to update cache internally.

    The consequences for this is that an API specification like ERPS must be assumed to be 100% stateless also, which typically means more overhead, as nothing can be assumed from a prior ERPS API call, page invocation, or customer/session state.

    This can lead to what appears to be additional data passed around, or additional overhead in fulfilling ERPS API calls, but again, this is done for stateless preservation, minimizing any assumptions being built in that assume a stateful operation.

    Note that this DOES NOT prevent the ERPS plug-ins, or external subsystems, from being stateful, if they support that, and can manage state properly, in the stateless calls back to ASPDNSF. Typically, ERPS add-on components or subsystems will do internal caching, to minimize communications latency and maximize performance. Obviously, caching must be done carefully, and with full knowledge and awareness of the ASPDNSF stateless requirement stated here.

    ...{more in the spec}


    Supported Platforms: ML v8.0+
    Attached Images Attached Images      
    Last edited by Rob; 01-08-2009 at 10:28 PM.
    AspDotNetStorefront
    Shopping Cart

  2. #2
    Rob is offline Senior Member
    Join Date
    Aug 2004
    Posts
    3,037

    Default

    more diagrams...
    Attached Images Attached Images  
    AspDotNetStorefront
    Shopping Cart

  3. #3
    Rob is offline Senior Member
    Join Date
    Aug 2004
    Posts
    3,037

    Default

    Ok, Spec doc is much futher along, and parts will be in BETA in upcoming Ashland release. WSI is fully production at this time already. If interested, send sales an email and we can send over the ERPS sync doc.

    This is designed for those larger clients do integrations with outside ERP/CRM systems (SAP, SAGE MAS, etc)...

    Good stuff!

    Our tax, shipping, and payment gateway plug-in provider model is also nearing completion in the Ashland Release (Master Pages also while keeping SkinBase for legacy skins or those who just like doing skins in DreamWeaver)
    AspDotNetStorefront
    Shopping Cart