mariovaldez.net
http://www.mariovaldez.net/webapps/forums/

Param module
http://www.mariovaldez.net/webapps/forums/viewtopic.php?f=12&t=167
Page 1 of 1

Author:  Redge [ 11 Dec 2004, 12:46 ]
Post subject:  Param module

Where i can find a doc for external module ?

How work???

What is the last param ???

Thank's

Author:  mvaldez [ 06 Feb 2005, 18:20 ]
Post subject:  External module docs...

Redge:

> Where i can find a doc for external module ?
> How work??? What is the last param ???


Sorry for this tooo late answer. :S


External modules are information providers used to update the data of products in the OSCommerce store. Currently there is only one demonstration module I wrote for a client, problably useless for people not in Latin America (because it uses a database from a mexican accounting software named SAE from a company named ASPEL).

The use of the external module interface is to update the products data in the OSCommerce store. Currently, only price, quantity, image name, weight and status can be updated. The interface works as follow:

The OSCPMWin application allows you to select a module from the Tools menu. Then it launches the executable file set in its configuration (Executable file), calling it with the given parameters (as set in Module parameters). Then it will try to create a TCP connection in the given TCP port (by default 27572).

If the connection is successful, the OSCPMWin application will start sending the given index data (currently it can be the product ID or Model) and will expect the answer for the module.

The expected behavior is that the external module will accept the TCP connection and wait for the ID or Model. When received, it will search in its repository (in this case, the SAE database) and will return a value. If the data cannot be found, it will return a code to let the OSCPMWin application know.

After sending and receiving all data from all selected products, the OSCPMWin application will show a confirmation window where you can review what data will be changed and what data was not found. Then you can accept or reject the changes.

There is another way to call the external module; the remote way. In this remote configuration, the executable name is really a host name. Then the OSCPMWin application will try to connect to that hostname thru the given TCP port and will try to do the same information exchange.

The external module application can also be used as a simple application launcher. If you set the "Just Run" option the application will be launched but not data exchange will occur.

The demo external module maybe will be useless to you, but it can give you an idea about how to design another. The demo module accepts 6 command-line parameters. The first one is a filename with the SAE Access database. The second is a table name. The third one is the field name used as index data (which will be matched with the product ID or model). The fourth is the searched field (which will be returned to the OSCPMWin application if the index field matches). The fifth is a TCP port to listen after launched. The sixth parameter if present, tells the module to show a more detailed panel about the transactions being made. The parameters are important for the external module only, OSCPMWin don't use them for anything.


The detailed communication handshake between OSCPMWin and any external module is still undocumented, but it is as follow:

* OSCPMWin application will start the TCP connection.
* The OSCPMWin application will send the first ID or Model of the list of selected products.
* The external module will reply with "OK value", where "value" is the found data, or...
* The external module will reply with "NOT FOUND", if matching data was not found, or...
* The external module will reply with "ERROR ERROR", if an error ocurred.
* After each reply, the OSCPMWin application will send the next index data (Id or model).
* At any time, the OSCPMWin application can send a "STATS OSCPM1" command.
* At any time, the OSCPMWin application can send a "QUIT OSCPM1" command.
* If the external module receive a "STATS OSCPM1" command, it will return the following data: total queries, records found, records not found, and records with error with the following format: "STAT description: value" for each value, followed by a CRLF and ending all with a "STAT END". Currently, the OSCPMWin application does not understand the stats, they are used only as information for the user.
* If the external module receive a "QUIT OSCPM1", it is expected that the external module will close the connection (and it may finish its execution if it is a local [non-remote] module).
* After all the exchange, the OSCPMWin application has created a sync list of values that are displayed to the user showing every record found, tagging each as to-be-updated, unchanged and not-found, as well as a summary of the data exchange with the module (including stats).


This interface is experimental. It is not mature. It will be changed for sure. I want to build a general two-way synchronization / importing / exporting interface for remote data sources. But I think the basic concept will remain.

The importance of using TCP connections is that allow the OSCPMWin application to leverage remote data sources in your LAN or thru the Internet, no matter the platform of the remote data source.

The data exchange protocol is supersimple. Maybe too much. But a XML-RPC or SOAP data exchange seemed overkill for me. At least now.


I think I have not forgotten anything. If you have any question, comment or suggestion, please post them here. :)


Regards,

Mario A. Valdez-Ramirez.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/