<SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">
How are business rules added to the site?<SPAN style="mso-spacerun: yes"> Is it possible to add them and then share them with other custom .NET software, such as when they are implemented in a .dll file that is installed with each product?



I will likely need to build some Windows Services to meet all of my requirements and it would be easiest to share all of the business logic. Does the BV Commerce framework support sharing logic with Windows Services or Windows Forms applications, such as when it is implemented with CSLA?

Sorry, let me give you some idea of what I had in mind. I would like to use a shared hosting provider for the web site and use some Windows Services to automate back end tasks, calling the web services to get any data access.

My current web site uses the CSLA framework, which allows me to share business logic throughout the organization without having to rewrite the data access or business rules. If a rule changes, I only need to update the DLL that my business rules are hosted in and redeploy it with the web site and any Windows applications I have written.

While this arrangement works great, the set of requirements I am currently working with are covered by the BV Commerce 5 product a little better, and a completely custom solution may be overkill. However, I am still a little reluctant to give up the CSLA framework in favor of BV Commerce 5.

I guess what I really need to know are the answers to questions like:

1. Can the middle tier components be used with Windows applications without having to do a significant amount of rework? More specifically, can I use the business logic in Windows without having to worry about calling functions that spit out HTML tags, depend on session state, etc?
2. What types of dependencies do they have (configuration files, resource files, registry access, unmanaged libraries, 3rd party libraries, etc)?
3. Do most of the middle tier classes support inheritance? For example, I need to have highly custom products with attributes that affect the price, size, and weight of the product. I will need to do custom shipping calculator work and express shipping options on a per-product basis. Is it possible to override the behavior of the current product class or perhaps inherit from an abstract class or interface to provide this functionality in the BVC5 framework?

First off, I think using the CSLA framework for extending the bvc5 architecture is extreme overkill. The best route to go if you are truely looking to make such extensive customizations is to simply purchase the developer pack of the bvc5 software. This will give you access to all of the source except for the Licensing module, UPS functions, and some payment gateways. You can then just modify the classes directly.

Now with that said, the bvc5 architecture has a lot of flexibility in its ability to be expanded upon without actually changing the core. Of the 3 examples that you have listed (highly custom products with attributes that affect price, size, and weight of the product. I will need to do custom shipping calculator work and express shipping options on a per-product basis), I do not see a problem implementing them without changing the product core. The built in product "modifiers" (you call them attributes) already support price and weigh adjustment, you would just need to extend that modifier to add size adjustment support, no need for core changes. As for your custom shipping calculator work and express options on a per-product basis, both are supported in Andy's Shipping Rate Provider Suite (http://structured-solutions.net/ProductInfo.aspx?productid=PROVSTE-5). For $199 per domain and $159 per domain if you purchase 5 at a time, it will saves you hours of billable coding time rather than re-inventing the wheel of what Andy has already done spectularly.

On a question by question basis:

1/2. All of the core files are class libraries (dlls) that have no dependencies from what I can tell other than the .net framework 2.0. However, some functions in the core do depend on session state because they rely on user state. This mostly comes up however when a function needs to run an entire workflow.
3. As previously stated, all of the things you mentioned can be done without changing the core and you could have them all for about 3 hours worth of work on adding a new product modifier and $199 per domain for the shipping suite.

I think (for me anyway) an actual example of something you are trying to accomplish would greatly assist the ability of forum members to tell what is and what isn't possible with bvc5. Specifically, how you are defining the "BVC Framework". Essentially since the store requires a database hosted somewhere and currently the database settings are stored in the web.config file, I do not think it is possible to simply take the Core dll and add it as a reference to a windows application and directly create an order in your database.

However, what you can do is use the Web Services exposed by bvc5 to create a windows application that makes a web reference to the bv store and utilize web service calls to create orders on the store from your software application, we have done something similiar to this.

As for your question on Business Rules, there are some extremely straightforward common tasks that are handled in what bvc calls workflows. Each workflow can have an unlimited (I think but the longest I've seen is really like 15 or so long) number of workflow task that each perform small functions related to the function of the workflow. Bvc has tried to take the common places of expansion and break them down into these tasks so that the Core does not to change to achieve your desired functionality. For example, there is a "Calculate Order" task that handle calculating the order total and discounts on each lineitem. It is broken down into such units as Apply Taxes, Apply Volume Discounts, Apply Sales, etc. You can re-write your own apply sales, etc task or create a new task altogether of your own.

The bvc architecture also dynamically loads several individual modules that are outside of the core to make expansion of other functionality possible without having to reworked the core. Some of them include the ability to add/edit product inputs, modifers, and choices implenting logic of your own (such as adding a field for size increases of a modifier), addition of shipping providers (Andy is extremely knowledgeable in this area), custom offers, custom content blocks to use throughtout your site layout, your own payment gateway, custom checkout procedures, category templates, and product templates.

Basically there is a lot of expandability available to the bvc platform but more direct and accurate answer could probably be provided if instead of saying "not standard estore features", you say, can I develop and interface for retail transactions that uses a touch screen to submit orders to bvc? Are can I create an application for a windows mobile device that will work with the bvc5 store?

While the original post was more of a general extensibility question about future expansion of the web site, I thought of an example that applies to this specific release.

One thing I have done to give me an edge over my competitors is make checkout quicker and easier. The product I am selling requires installation and there are 3 different choices for mounting hardware. On my current site, I added the mounting hardware as a dropdown list to the actual product. This prevents the customer from having to order 1 specific piece of hardware with the product and then go back and shop for one of the other choices (which is what they really want). It also allows us to give the customer a discount on the hardware if it is ordered with a product vs if the hardware is ordered seperately.

While this all sounds good on the surface, when tying this in on the order fulfillment side, the item that is in the dropdown list is actually supposed to be a seperate lineitem from the product. In addition, the product has a color dropdown, and some of the mounting hardware also has a matching color. If the customer chooses a color for the product, the same color should be entered into the cart for mounting hardware (if applicable). Before I go into how I resolved this issue, there was one more issue that I should probably describe first.

The unit of measurement of the product is a pair and most of the time it doesn't make sense for the customer to order 1 at a time. So, to make this work when the customer specified a quantity of 1 they were actually getting 1 pair. However, in rare cases there were times when it made sense to order only 1 (or 1/2 pair). So to account for this, my current site also lets the customer choose yes or no in a 1/2 pair dropdown, which will give them a discount off the total price of the product if the 1/2 pair is ordered.

Again, there is the issue with converting this on the fulfillment side from "1/2 pair = yes" to quantity 0.5.

Now that I have described the problem, lets go into the solution I came up with the first time around. Lets also start with the first issue I presented - the choice of mounting hardware.

One thing I had to keep in mind is I wanted the customer to be able to edit the item after it is placed in their shopping cart. While just breaking the product into 2 lineitems and adding it to the shopping cart may sound like a viable solution, it would be a little confusing if the customer saw that when they added just 1 item to the cart, it would produce more than one lineitem within the cart. Also, when you consider what will happen when the customer clicks the "edit" button for the original product (in the cart) - when shown the edit product page, the hardware options should no longer be visible (after all, we are only editing the product lineitem, not the hardware). Furthermore, when a customer orders more than one similar product, they generally always use the same mounting hardware. Let's say the customer ordered quantity 3 of 4 different products. On the fulfillment side, it would be more confusing to see 4 lineitems with quantity 3 for the hardware than it would be to see 1 lineitem with quantity 12. The different products on the other hand should remain seperate lineitems. Therefore, it would be more natural to "roll up" the matching lineitems when it gets to the final invoice.

To fix this issue in CSLA, it was fairly straightforward. I left the shopping cart as-is, so the customer could add and edit the items without having to see different views of the options in each case. When the customer checked out, that is where things needed to change to accommodate the fulfillment process. So in the database schema, there wasn't just one table of lineitems related to an order, there were 2. The original data that the user entered was kept for editing purposes (after checkout, in case the customer changed their mind). In addition, there was an "invisible" lineitem table that rolled up the similar products. The order management application is Windows-based, and CSLA made it very simple to write all of the logic once for both the web site and order management application.

To populate this "invisible" table, CSLA made the task very easy. It kept track of a seperate collection of data associated with the order. Whenever the data changed on the order, the seperate collection was recalculated automatically and all of the logic for choosing the appropriate color and quantity on each lineitem was included in the custom CSLA business objects I created. When the data was saved, it was done so in a transaction so the 2 tables could never be out of sync.

Finally, on the fulfillment side a PDF report (packing slip) was generated and emailed to each drop-shipper based on the 2nd "invisible" table that only had the lineitems of seperate products. This ensured that as few errors could happen in the fulfillment process as possible. The first version of the application used the same view on both the customer and fulfillment side (with all of the options shown as a child list of the product), and there were many errors caused by the confusing packing slips that were sent to the drop-shippers.

Now that I have described the problems and CSLA solution in detail (I hope to the point where they are understandable), I would like to hear some opinions on how these problems could be resolved using BVC5. While one might argue that just putting the hardware as a "related item" could solve the hardware selection issue, this is not something we are willing to consider since it gives us a big advantage in a competitive market to keep this a dropdown on the product itself. It would also be very error prone on the customer end, since this product should never be ordered without hardware. In addition, that approach doesn't help solve the the 1/2 pair issue.

I didn't mean to sound so negative about BVC5 in my prior post. Looking at the list requirement by requirement, BVC5 supports about 70% of what we need to do, while the current site only supports about 40%. It is solving issues like this that could be a make or break decision on whether we actually use BVC5, though because they have already been resolved on our current site. So there is a little bit of "why reinvent the wheel?" we have to consider in both cases. It would be useful to us to know if there is a simple resolution with BVC5 that doesn't require a major hack. It would also be useful to know if the issues that I described here can be resolved without editing the core source code for BVC5.

caplink,


It is good to hear that someone else had to struggle through this one, at least I am not alone on this.



Now are you saying that when the product is added to the shopping cart it is split into seperate lineitems, or after the order is submitted? If you are saying that it is done during the shopping cart, how did you deal with allowing the user to edit the items (editing the item would not need to show the add-on item)?



Did your main product and add-on products have a common attribute like color that you had to account for? If not, is that something that you think could be added without too much trouble?



No help on the 1/2 pair issue...






If I commit to this product, any chance you will share your solution with me or am I on my own on this one?

[/quote]

Hi dotNet guy,

As for your first post, our application caused the split to occur directly when being added to the shopping cart. However because of the workflow architecture it could easily be done in after the customer selects place order.

In terms of common attributes, no I have not had to deal with that, however since you can tag anything you add to the cart with any property you want, I can think of numerous ways of implementing what you are looking for. As for the half pair issue, I can say I find that unique and if I was a customer I would also find it quite confusing. From a customer's perspective I'd rather see there be 2 different part numbers for a pair and for a single unit if you feel for some reason that the product absolutely needs to be sold in pairs. From a programming perspective, the best implementation I can think of would be to sell it as a "1/2 pair" in your actual product sku and then have a workflow task inform the user that that particular product is typically ordered in pairs and give them the option to change their quantity.

Bvc has facilities for making any changes you want. Most if not all of the ones you have suggested can be doen without changing the core.

caplink,

Thanks for your help with this issue - it really is probably the biggest hurdle I am trying to work through with BVC5, otherwise it would probably be a slam dunk to buy it.

Well, I am not selling shoes but it is a similar concept to the products we are selling. It makes sense to almost everybody to buy them in pairs. Unless of course you are talking about a guy who only has one foot. The ratio of people who will need pairs to the number that will need single items is about the same (maybe slightly more) in my case. On top of that, all of my competitors are selling in pairs so it would even be more confusing to sell the product individually to our customers if we were doing it differently than everyone else.

On the other hand, none of my competitors offer 1/2 pair. I have received several orders simply because I was the only one who offered 1/2 pair. If it is cheaper to buy 3.5 from me than to order 4 from my competitor, I will get the sale. Most people would not hesitate to order from me than to buy something extra for $20-$60 and have to throw it in the garbage because they can't use it. None of their friends or neighbors can use it either because it was custom made for them. It is definitely worth it to us to work this out rather than not offer the option.

Now, I built some code that synchronizes 2 tables of lineitems in my current system and I can definitely do it again. So let's assume for a minute that is the solution we will use. The only thing that really matters to us are all of the features in BVC5 that downstream from the order will depend on the lineitems. Two examples I can think of would be the shipping calculation and inventory features. We will most likely not be using the inventory features (definitely not in the first release anyway). The actual packing slip could be generated based off of the generated table similarly to the way it is done now. Are there any other features that have dependencies on the lineitems of the order in BVC5 that need to be taken into consideration? Since the two lineitem tables will essentially consist of the same data, we may not need to alter too much to get this to fit, although I am pretty sure the package & shipping calculations will need to be done from the generated list of lineitems.

Andy,

I took a look at your shipping calculator module and I like the features it provides (especially the Amazon.com view). If I have to generate 2 lists of lineitems to make both the customer view and the fulfillment view (which would contain the item size and weight) less confusing, will it still be possible to use your shipping plug-in? Is there some way to tell it to look in a different place for the package quantity, size and weight information than the BVC5 table?

Andy,

Thanks for the info. I think based on your assessment we can at least get our products into BVC5 (whew). Because of the level of customizations we are planning, we weren't considering buying BVC5 without the source code, but it is nice to know what can and can't be done without altering it.

Specifically what I meant by "customer view" and "fulfillment view" is that (unless we can come up with a better solution) we would like to store 2 sets of lineitems that are related to the order. The first set would be the standard view that the customer sees on the website, which is also the view that is currently supported by BVC5.

The second view is one that breaks out the actual items and quantity from what the customer has chosen in the first view. Essentially, when the customer selects they would like to buy some hardware with the product from a dropdown or that they want 1/2 quantity from a dropdown, we would use some custom logic to create an "inventory" list that splits the add-on items selected on the product into individual lineitems. This view is required to prevent confusion on the fulfillment side and also to ensure that items that are fulfilled by a different shipper will be physically stored as a seperate record.

Using this approach, the package weight and size information would need to be stored in the fulfillment view (because this information would also be calculated based on user selections of the product). We would just need to make sure there is a way to pull the data from this other view to assist with package size and weight calculations during checkout, and it sounds like this can be done by modifying the Order and Catalog API to pull some of its data from another source.

Now, I am hoping the "Order and Catalog" API has a parameter passed to it that indicates what order number we are referring to for the package calculations. In our case, the catalog won't contain the information we need (at least not in the correct format) so we will be determining the size and weight information on a per order basis, not just what is contained in the catalog. Is order number passed into the API when retrieving this information?

Also, what specific methods in the core does your shipping module call when retrieving its information? I can use reflector on the core in the demo to find out the rest of the interface information to determine exactly how (or if) this can be done before I commit to a purchase.

dotnetguy,

It's clear that you have a lot of pre-sales questions. I think your questions could be better answered by calling our sales line at 877-306-7393.