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 1 of 1

Thread: WSI Forum Overview

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

    Default WSI Forum Overview

    WSI OVERVIEW

    WSI is the Web Service Automation Interface v1.0 for AspDotNetStorefront ML v7.0.2.1 or higher.

    The WSI manual is here http://www.aspdotnetstorefront.com/manual/wsi

    WSI is a developer oriented feature, and requires programming to use.

    This web service replaces all prior bulk import routines, while still supporting all prior bulk import features such as Excel file imports.

    WSI is designed for programmatic & automatic add, update, and deletion of AspDotNetStorefront database information from external agents (e.g. accounting systems, CRM systems, ERP/Inventory system syncs, etc).

    The objective of WSI is to facilitate other vendors (e.g. CMS systems, Fulfillment Systems, Accounting Systems, etc) to import, export, update, and sync data with AspDotNetStorefront, and allow developers to more easily perform these custom automation/syncing tasks for client projects.

    WSI Abstraction Level

    In WSI v1.0, the implementation consists of rather low level, but very powerful and flexible, set of base interface processing node actions (e.g. Set, Get, etc). We will use this base implementation to build higher abstraction elements over time as needed. Developers will find this low level, very flexible interface very customizable and powerful when doing custom integration projects.

    You should use the highest abstraction element provided in the WSI when possible, as it may perform additional semantic processing (e.g. you could issue a node against the ProductVariant table to update a variant price, or you could use the product pricing update action that can do this same thing, which also has more semantic understanding of how products work, so it may be prudent to use the higher level abstraction element.)

    Developers can fully customize how the WSI sends resulting Xml data also using custom XmlPackages, which can be deployed, and invoked via the WSI. These XmlPackages can be used to handle almost any data sync query you, with complete control over XSLT transformation of output Xml that you may need.

    Using ID and GUID fields

    Whenever an ID or GUID is referenced in the WSI document, the ID corresponds to the identify field (or other primary key field) of a table (our primary key on every table).

    Nearly all of our tables have identity fields, which auto assign. You CANNOT force the db to use a specific ID (e.g. product id 14) on any add operation!


    You can however pass in a GUID (that you provide) that can be assigned, even on data creation or add, and then you can later use that GUID to correlate to our internally assigned (category, product, manufacturer, etc) ID. Each WSI action returns both the ID (which was auto assigned) and the GUID associated to it. If you do not provide a GUID, we will auto-generate one like we do internally for any add operation.

    The GUID corresponds to the GUID field we have in almost every table.

    Note that the "ID" field may be called differently in different tables (and the ipx.xml file has the mappings for non-standard fields, or those needed for performance). For instance, the "ID" field on an Orders action corresponds to "OrderNumber". The ID on a Product action corresponds to ProductID.

    Just think of ID as the master identity of the table, and you will have no trouble making the associations.

    Remember to assign your own GUIDS to all nodes, if you must keep the master "ID" lookup on your system external to AspDotNetStorefront.

    Updating Data Via WSI

    The WSI supports "update" actions against existing data. The special cases to consider are as follows:

    If you want to leave existing data in the db alone (unchanged), just omit the XmlNode from your input document
    If you want to clear/erase existing data in the db, just send an empty element (e.g. <Description/>) and we'll set it back to either an empty string '' or NULL, depending on the field.
    CDATA FIELDS

    Most text based fields (e.g. Description, Summary, etc) can be sent in as CDATA nodes on that element if you find that easier. This sometimes is easier when you are sending in field content which itself contains HTML (e.g. product descriptions).

    System Requirements

    WSI requires AspDotNetStorefront ML v 7.0.2.1 or higher.

    WSI with full encrypted authentication requires Microsoft Web Services 3 (WSE3) Enhancements to be installed on your server. You can get the Microsoft WSE3 download here.

    Do not leave the ipx.asmx page unsecured on your site if you are not using it. Follow all security guidelines documented herein!

    Delete the file from your site, or do not deploy that file, if you are not using the WSI interface!

    If you are using the WSI interface, rename the ipx.asmx page to something less obvious and unique for your own site (e.g. mywsi4334abc.asmx, or whatever you want).

    Always run the WSI over HTTPS protocol in production.

    Change your passwords regularly according to our v7.0 PABP best practices manual guide.

    EXAMPLE CLIENT

    See manual for further/latest information and updates including a sample WSI test client windows program you can use as a starting point.

    WSI EVENTS

    WSI Events (outbound notifications) are also documented in the manual

    ML/DNN SUPPORT

    WSI is not supported on ML/DNN platform at this time.
    Last edited by Jesse; 01-26-2009 at 12:14 PM.
    AspDotNetStorefront
    Shopping Cart