Thread: Why use WSI?

Hello.

I'm just trying to see the "big picture," and I can't really see the need for WSI, and I'm hoping someone can set me straight.

Basically, WSI seems like it's designed to be a "portal" or a "window" into the AspDotNetStorefront, but it seems like it's only used to add records to the database. Isn't it a lot easier to just use the stored procedures in the database, or even make some of my own if I don't find the ones I need?
I feel like I'm missing something, but it seems like a lot of extra trouble to install and figure out the WSI stuff if I don't really need it.

So, please....enlighten me. Obviously, there's something I don't see.

Thanks,
Jay.

Think of WSI as an extension of the existing application (including stored procedures). WSI can be used for a number of things other than just adding records to the database. In it's simplest form, it can be used as an import tool for inserting records directly into the columns of a database table (you can write direct sql statements and pass them in) or via some of the built in nodes like Product, Entity, and Customer. In addition, using native WSI functionality ensures that data is inserted in a manner native to AspDotNetStorefront, and you don't run the risk of leaving out some crucial piece of data required for the store to operate properly as you do with direct sql statements. The flexibility of WSI however, does allow for direct sql statements, as well as stored procedure executions:

Code:

<AspDotNetStorefrontImport Verbose="false">
<Query>
<SQL>
<![CDATA[
exec aspdnsf_GetCustomerByID 58746
]]>
</SQL>
</Query>
</AspDotNetStorefrontImport>

Getting slightly more complex, WSI can be used to update, soft-delete, or nuke items in the database (again either via direct sql or the included nodes and methods that are native to WSI). Due to the nature of WSI, you can perform these functions based on what you know about the data you are trying to delete rather than trying to gather the data that the stored procedure requires (eg. instead of exec aspdnsf_someprocedure parameter_1 parameter_2 parameter_3 you could pass a delete from table where somevalue_1='value_1' and somevalue_2='value_2' where somevalue_3 not in (select value from table_2 where table_2_value_1 = 'value_1'). You are completely free from any confines that a stored procedure might limit you to.

Moving deeper into WSI, you can perform a plethora of other tasks including (but not limited to) order processing (there are ~34 different order processing tasks that cannot be accomplished through stored procedures which WSI is capable of, including Voids, Captures, Refunds, sending receipts, marking an order as fraud, marking an order as shipped, retrieving receipts, deleting, setting tracking information, etc...), recurring order management, inventory retrieval, resetting the cache (as you would do from the admin section), and uploading images for products or entities while utilizing the image resizing features. Since WSI is completely XML, you can also utilize our xmlpackage engine and xmlpackages to format data however you see fit.

WSI also goes hand in hand with our event notification system. You can configure AspDotNetStorefront to provide notifications of different events (like a customer creating an account or placing an order) which call out to a page on the web. From that page, you could use WSI to retrieve information and do something with it. For example, let's say you have a third party application where you back up all of your order data. After a customer places an order, AspDotNetStorefront sends a notification to some listener page you've specified with an order number and the type of event - New Order. The listener page can grab the order number from the event notification, use a simple Get statement with an xmlpackage specified that formats the data in a manner your other application understands:

Code:

<AspDotNetStorefrontImport Verbose="false">
  <Get Table="Orders" Name="NewOrders">
    <XmlPackage>DumpOrder.xml.config</XmlPackage>
    <Criteria OrderNumber="#####"/>
  </Get>
</AspDotNetStorefrontImport>

and then pass the data off to your third party app.

From here, the possibilities are endless. Want a desktop application for bulk capturing orders? Write a simple application similar to the one we offer for download in the WSI manual that you can execute from your machine with internet access, which when clicked will retrieve all non-captured orders from your site, save each one off into an excel file somewhere on your local machine (just to keep a record of what's going on) and then captures each one.

Have multiple licenses and have multiple stores set up that share inventory? Write an xml doc that you can pass to WSI that retrieves inventory for an item from each of the sites available, determine how many were sold for the day and updates the inventory across all the sites to reflect the proper amount. You could even tie this up to the event handlers so that it happened automatically every time someone purchased an item.

WSI is suited for anyone wanting more than just an import tool, that can be used over the web without direct access to the database and outside of the application. It can be used for cross-platform communication (I've recently implemented WSI for internal use across .NET and php where the two applications aren't even aware of each other), as well as simple maintenance and management of any data that exists in AspDotNetStorefront. If you're interested in a simple xml format import tool, it can be used for that as well.

If you'd like any clarification on any of this, or are interested in some of the other capabilities of WSI and AspDotNetStorefront, feel free to ask. WSI has personally become one of my favorite features that AspDotNetStorefront has to offer, and has the capabilities to extend the platform in almost any direction anyone could hope to take it

George,

Very well written and great explanation of what WSI is. Personally, I see soooo much potential for WSI that I get giddy just thinking about it.

Example, I am currently running two stores both on the same PHP based cart. Im in the process of migrating 1 of these to ASPDNSF. WSI has helped immensely in importing of all products and inventory. Now, next step will be to work with WSI to keep inventory in synch between PHP and ASPDNSF. My next step after that is to integrate with my warehouse management software. It is a home grown solution that currently reads orders directly from the database. With SQLServer, my host doest like to allow open direct access to the db so I am using WSI to bring the orders into my system. From there we process (pick/scan/ship) and at the end of each ship day Fedex Ship Manager writes back to my database to update tracking and mark as shipped. Again, since I wont have direct access to the db I am hoping to use WSI to take care of this. I will most likely have Fedex dump the tracking info to csv and I will have an app pick this up and process sending info off to ASPDNSF via WSI.

I can't say for other systems and methods, but in our store WSI is the only way to communicate, and until it was written we couldn't do the storefront project like we wanted. We write software on our mainframe to the WSI standard, pipe the data to a XP box, and a program that we wrote for the XP box polls a directory location then pushes the data to the storefront, gets a response and places the result in a file. The mainframe polls waiting for a response file to show up, we then process the response and mirror the entire site's operation on the mainframe. The Mainframe software looks for deltas in our inventory, new items, description changes, etc, then data records are created for WSI to communicate to the storefront hourly. It is a huge undertaking, but with 500,000 items, we had no other method to effectively communicate bi-directionally with the mainframe.

Bumping to the top...WSI is one of the most powerful tools AspDotNetStorefront has to offer. In addition, WSI can be used in conjunction with our upcoming add in functionality (using the System.AddIn namespace) that we'll be presenting on at our upcoming developer conference in July to extend the application in ways never before easily accomplished

If you are trying to integrate remote systems to your store then it's a fairly useful tool. We've used it with the 7.0.1.1 system to upload product data every night and download order data.

The system is very useful, even though in my opinion is a little bit unorthodox if you were to compare it with SOAP Web Services.

But the tool is relatively flexible and the documentation is good. If you have a remote system, then it's a good bet for you... if you have local access to the system and you're doing relatively simple operations, then go to down with your SQL connections.

...a little bit unorthodox if you were to compare it with SOAP Web Services.

Could you elaborate a bit? WSI is capable of consuming SOAP 1.1 and 1.2 calls, and I've the implementation I mentioned earlier regarding WSI being used across a .NET application, and a .php web applications are done using SOAP calls. Do review the syntax, browse to the webservice URL (eg. should be something like http://localhost/AspDotNetStorefrontML8012/ipx.asmx) and click on one of the exposed operations

@George: I have a client whose business requirements demand that their backend system control customer and order creation. Is it possible to use either WSI or ERP add-ins to accomplish this in real time. For example, I need to be able to pass customer data to the backend (which will create the customer), have the backend return the customer number and then use that customer to create an order (also on the backend) and do this in real time.

I have read the WSI manual and ERP add-in spec and it seems like only WSI may by used for customer and order creation. Is this correct, and if so, can this function in realtime with adequate performance?

The ERP AddIns are designed more as an integration piece for syncs from AspDotNetStorefront to BackEnd systems and to add additional functionality to AspDotNetStorefront without modifying core AspDotNetStorefront logic. For example, an addin would be used to retrieve inventory in real time during the add to cart and checkout processes from the back-end ERP system. An addin could also be used to check the contents in the cart and offer promotional or extended shipping methods and rates during the checkout process on the shipping calculation page. You could also use an addin to notify a vendor and sync a back-end system when an order is placed.

WSI would probably be your best bet here. Because of the nature of AspDotNetStorefront, managing customers and orders ONLY off-site isn't feasible without modifications to the overall architecture, and therefore addins probably aren't going to be your best bet (unless you want to use addins to sync the information from AspDotNetStorefront to your back-end system when some event occurs within AspDotNetStorefront).

Can you elaborate a bit more on the setup and overall what you're trying to accomplish? I may be able to offer more in-depth suggestions for the integration if I know exactly what you're trying to do (eg. where do they enter in their information when the customer needs to be created...is it a site that is tied directly to the ERP systems web site...what roles is AspDotNetStorefront going to play (just products and inventory?), etc...).

@George: thank you for you reply and hopefully these additional details will help.

The goal is to have the backend system manage as much of the business logic as possible. The storefront would manage products, product categorization (menus and other navigation), seo, cart and checkout. The backend would generate and store customer records, quotes and orders. Currently pricing is a hybrid between the frontend and backend for performance reasons. There is no inventory requirement.

Here's how the process works today: Anonymous customer enters site and sees content (products) from the SQL database. Customer may add an item to the cart (also on the front end side managed by the sql database).

When customer goes to checkout the customer data is collected and transmitted to the backend. The backend creates a customer and returns the customer number to the front end. The front end then generates an "order" in memory and transmits this to the backend. The backend generates a quote with shipping and tax addons. This info is displayed on the place order page. If the customer places the order then the quote is converted to an order on the backend. (The front end handles all of the credit card processing.)

It's ok if customer data and order data is stored on both sides. The important part of making this work is having the ability to send and retrieve customer data from the backend; and to generate orders on the backend and update the tax and shipping charges on the frontend with values obtained from the backend. This sounds complicated but it actually works well on the current site. An upgrade to aspdotnetstorefront is being considered so that we could take advantage of the great way you handle the display and management of products and related content.

So I'm interested in whether or not WSI would be a good fit. Please let me know if you need any additional info. Thanks.

I am in the process of investigating which e-com to buy.

I have read long about your software, which seems to fit a capable .net programmer as myself.

My question is this: our budget is to buy piece of piece at the time. We have our own custom stuff. We have developed a simple warehouse scanner, which simply does one thing: set orders to "shipped". Does I require WSI for this, or will it be pretty simple to set this status via PROC's?

B.R

Christoffer Munck

for that, you could just poke the shipping status into the DB via SQL/proc. that's fairly easy to do. WSI is designed for quite a bit more than that (although it could do this also of course).

anyone else out there use the WSI Test Client?
i used it a couple months ago to import records into my storefront.
now it's time to use it again and it's suddenly failing authentication.
the only thing it asks for (as far as authentication goes) is for the email address of the admin account, and the password of the admin user. i have double and triple checked them and they are correct and yet i still get an authentication error.

anyone have a clue?

here's my error:

System.ArgumentException: Authentication Failed
at ipx.DoItUsernamePwd(String AuthenticationEMail, String AuthenticationPassword, String XmlInputRequestString)

Do you have the Use WSE3 Token Authentication checkbox ticked? If so, you must use the hashed password from the database. If you want to use the plain text password you have to uncheck that.

You may also want to try logging into your admin section. It's possible that your admin password has expired and you'll have to change it...if this is the case you'll have to change it and then try the import tool again.

the box is unchecked
the password is correct
i even tried changing it and resubmitting
no matter WHAT i do.....i get the authentication error

If you browse directly to the service URL on your site (the URL you type into the import application), do you get the list of services available?

I have been searching for a solution to our needs, and have had a real struggle. WOndering if WSI would be a fit. Here is a bit about out situation:
We have a photo app that is used by venues to take photos. We give the customer a ticket, which they can scan at a kiosk on the premises. We want them to be able to order directly from the kiosk. We want the customer to be able scan their credit card and place their order for pickup on premises.

We have ASPDNSF set up to be accessed from the photo app in a fancybox iframe setup. We can get to the SF just fine, but during the order process, we have issues of too many steps and too much data for a customer to add at a kiosk.

Would WSI be a solution for use to create the orders after we pull the limited info we need from our existing app? If not, is there another option that is available to accomplish this?

I am getting despirate here as our deadline is quickly approaching and I need to figure out a solution.

Thanks in advance...