July 22, 2008 - 7:21am
This sounds like a perfect
This sounds like a perfect use of XML.
In my job we have one central data source that literally hundreds of applications need to pool from. What all the applications do is build an xml document request that gets sent to the data source server. Once there, it's validated against a transaction code node to see what type of transaction we want to query the data source with, then it returns that data, via xml, back to the calling application where we parse it into some kind of dataset, as most our transaction return multiple rows, and they we query that dataset.
That's a very simplistic top level view of a much more complicated system, but XML makes it so much easier to get all these applications to play along and it would be worth your time to maybe look into this further looking into further.
Outside of that you're going to have to come up with something custom that is going to have to be managed across each shop.
July 23, 2008 - 2:57pm
Thanks for that Paul. I
Thanks for that Paul. I agree, XML would be really good, and I think we will try to go down that route. I've not used it before, so I'm going to look into it, but presumably we would write a specification so that when we send a request the other one knows what we are asking and the way to respond?
July 25, 2008 - 7:53am
Ideally, you would have one
Ideally, you would have one central shop, "parent shop", that would handle all the incoming requests from the child shops. The parent shop would contain a program whose sole job it would be to route transactions.
I could start by making a xml document with two node sets. An header node set and a transaction node set. The header section would contain only information about the calling shop and what has to be done with the data. In this case I'm calling it a transaction code. The transaction node set would be the actual data to process.
A quick mock up of the xml document might look like this:
CODE
<?xml version="1.0" encoding="UTF-8"?>
<shoptrans>
<header>
<callingshop>Shop A</callingshop>
<transactioncode>Process A</transactioncode>
... more ...
</header>
<transaction>
<order>
<order_date></order_date>
<order_sales_id></order_sales_id>
... etc ...
</order>
<item_number></item_number>
<other_information></other_information>
... more ...
</transaction>
</shoptrans>
<shoptrans>
<header>
<callingshop>Shop A</callingshop>
<transactioncode>Process A</transactioncode>
... more ...
</header>
<transaction>
<order>
<order_date></order_date>
<order_sales_id></order_sales_id>
... etc ...
</order>
<item_number></item_number>
<other_information></other_information>
... more ...
</transaction>
</shoptrans>
A very top level view of what the logic would look like would be:
July 28, 2008 - 1:05pm
July 28, 2008 - 3:00pm
Seems like couchdb would work
Seems like couchdb would work better than xml.
http://incubator.apache.org/couchdb/
I'm not hopeful about this, but I may as well ask anyway. Does anyone know if there are any standard specifications for web services that are meant for online shops to talk to each other.
The scenario is that the customer is with Shop A, but the order fulfillment is being done by Shop B (the customer is unaware of this). So, for instance, Shop A will need to ask Shop B if it has stock of a certain item, and tell it to send the item to the customer etc. The problem is made difficult because there will be one "Shop A", but many "Shop B's", if you see what I mean. We don't know what the "Shop B's" will be running for stock control, so they would all need to implement Shop A's web service standard. If there was already some standard protocol (possibly already implemented by many online shops), it may be easier to persuade them to implement - otherwise we will have to invent our own and force it on them.
Any ideas? Cheers!![]()
/rolleyes.gif" style="vertical-align:middle" emoid=":rolleyes:" border="0" alt="rolleyes.gif" />
~Andrew~