SVG 2D Graphics Research
Logistic Procurement Architecture

Logistic Procurement

Not quite finished - coming soon. Please read on to see what will be there when the demo is working.

You have a catalogue from which people can order. When they place their order, you would like to show them graphically what they have ordered, to cut down their errors and reduce the number of Product Returns.

What is stopping you? The Combinatorial Explosion problem.

Your product line seems simple enough, but it has a hidden block to web work. It has only 100 products. And for a typical product, there are four basic models, each having three different motors, two different kinds of controller, and it comes in three different mounting assemblies.

You have a web site for customer orders, and you want them customer to receive graphics showing them what they have ordered. But your web developers say that they can not possibly do all the graphics. You ask why not? They say that they would have to photograph every different combination of features for all 100 products. They point out that your typical product has 72 different possible combinations of features, and that makes 7,200 photographs to be taken and then transferred to the web site. it is labour intensive, error-prone, and will need constant maintenance.

That's the combinatorial explosion problem. All those combinations of features. There are only 4 of these and 3 of those, etc; but they multiply up to make some horribly large numbers.

The huge and unique benefit of programming is that one program can reflect different possibilities. A single program can draw a whole family of things, given the right parameters, and even multiple related families.

So a single Graphics App can draw at least one product, and maybe several.

That means that the web development team can construct just a range of Graphics Apps, numbering maybe in the 10 to 20 range, instead of trying to manage 7,200 different 'dumb' pictures. Plus, many Graphical components would be shareable between Graphics Apps, so there would typically be further savings of time and effort.

Assume that your server-side DP App is written in PHP (but it could be Perl, java, etc)

Your user enters order codes in a list on a web form.

1. Each time they enter a code, the data is transmitted to your PHP App
2. The PHP App gets the parameters from your product database and sends the code-plus-parameters to a Graphics App (PenDraw is ideal for this)
3. The Graphics App draws the component, producing SVG, complete in all its variety
4. The Graphics App returns the SVG to the PHP App.
5. The PHP App re-produces all the XHTML (or HTML or XML) for the order page, including the SVG as an <object>
6. the customer moves to the next item

Remember, your SVG graphics can also be interactive. Each graphical element can respond to the mouse, and you can program client-side in javascript or VBscript, and pass interactive moves made by the user back to another server-side script. The potential is enormous. As with many other of the architectures we have shown here, your Logistic Procurement Architecture can become a part of a whole enterprise architecture.

Remember, too, that any part of the SVG graphics picture can act as a hyper link, so you can construct documents that have rich semantic structures, and offer the user natural and helpful interfaces.