ich habe mich heute nach einigen freien Warenwirtschafts-Systemen umgesehen, und die Frage kam auf, ob und wenn mit welchen, eine mglichst reibungslose phPay Einbindung mglich wre.
Stndiges Im-/Exportieren ist nicht wirklich praktikabel, zumal Artikel aus dem Warenbestand auch auerhalb des Internets bzw. dieses einen Shops vertrieben werden sollen, und eine doppelte Transaktionsabwicklung nicht wirklich zeitsparend und bersichtlich ist, vor allem wenn man nicht extra jemanden fr die Buchhaltung einstellen will/kann.
Mich wrde einmal interessieren, wie andere diese Probleme gelst haben.
Danke fr Eure Tips.
PS: sorry fr das doppelte Posting, aber mir ist irgendwie erst auf den zweiten Blick aufgefallen, da das Posting in diesem Forum wohl besser aufgehoben sein wird :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kannst Du Deine Vorstellungen der Anbindung przisieren? Fragen die fr mich noch offen sind:
- Wie soll ein Abgleich stattfinden?
a) nur Daten von WW(Warenwirtschaft) -> phPay
b) WW <-> phPay
c) Bestellungen phPay -> WW
- Was fr eine Rechnerumgebung hast Du?
Die Schwierigkeit ist vorallem, da der Webserver, auf dem phPay (oder sonst irgendeine Shopsystem) werkelt, nicht selbst aktiv wird, sondern immer nur Anfragen bearbeitet. Von naturaus wird der Webserver also nicht irgendwelche Importroutinen aufrufen. Das liee sich aber noch entweder ber Cronjobs (einige Provider bieten das an) oder den Taskplaner lsen (1).
Zweites Problem: Wie kommen die aktuellen Daten zum phPay-Webserver. Vielleicht per automatisiertem FTP-Upload (2)?
Was kann Deine WW? Mut Du dort aktiv werden, um Artikel zu exportieren; erfolgt das automatisch nach jeder nderung(3)?
Mein Hardware-Hndler macht das so: Aus seiner Warenwirtschaft werden alle 15min Daten ausgelesen und in eine Textdatei geschrieben(3). Diese Textdatei wird per FTP automatisch hochgeladen (2) und dann verarbeitet (1).
Im Sinne von phPay knnte das hnlich ablaufen. Die Textdatei wre eine CSV-Datei, die Deine Warenwirtschaft produziert (3). Automatischer Upload ist nur eine Sache Software. Von WSftp, wei ich da es funktioniert. Auch andere FTP-Programme werden das knnen, auch unter Nicht-Windows. Auf irgendeine Weise mu dann nur noch eine leicht modifizierte importitem.inc.php aufgerufen werden, die eben direkt auf die zu importierende Datei zugreift und keine erwartet, die per HTTP hochgeladen wurde.
Die ganz andere Variante ist: WW und phPay laufen auf der gleichen Maschine. Dann kann die WW direkt in phPays Datenbank schreiben :-) Das ist sicher das eleganteste und schnste. Aus phPay-Sicht will einfacher. Dafr sind dann andere Gegebenheiten wichtig: Anbindung, Hardware usw...
Weiterer Vorschlag: Die WW bernimmt den automatischen Upload nachdem sie die Daten exportiert hat und ruft dann die entsprechende Webseite des Shops auf.
Gru,
Andreas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
danke fr Deine umfangreiche Antwort. Eine Mailingliste statt des Forums wrde Diskussionen erheblich vereinfachen, da man da ordentlich Quoten kann und richtige Threads hat :-)
Zu Deinen Fragen:
es sollte ein bidirektionaler Abgleich stattfinden, also WW<->phpay, da ja in beiden "Welten" Artikel verkauft werden, die von einem gemeinsamen Lagerbestand abgehen.
Als Rechnerumgebung wird ein Linux zum Einsatz kommen. das phpay wird auf einem dedizierten Server bei einem Provider laufen, auf dem ich vollen root-Zugriff via ssh etc. habe. Als Datenbank wird Postgresql eingesetzt werden, da bisher laufende Lsungen diese auch schon nutzen.
Eine Wahl zum Thema WaWi-Software ist noch nicht getroffen, das wird davon abhngen wie (gut) sie sich mit externer Software verbinden lt. Eine kommerzielle WaWi wird nicht angestrebt, da ich Wert auf die eigene Erweiterbarkeit einer unter GPL stehenden Software lege, was allerdings die Auswahl erheblich einschrnkt ;-(
Da am Arbeitsplatz keine Flatrate mglich ist, wird die WaWi wohl nicht auf der gleichen Maschine laufen knnen, wie der Shop, was den Abgleich erschwert.
Mglicher Ansatz der mir bisher eingefallen ist:
- Kunde bestellt im phPay
- mail wird generiert
- fetchmail holt mails ... procmail stellt fest, dass es sich um eine Bestellung handelt und bergibt die Mail an einen Parser.
- der parser nimmt die Bestellung dann auseinander und pflegt sie in die Datenbank der WaWi ein.
damit htte man schonmal eine Synchronisierung phPay->WW
fehlt nur noch der Weg WW->phPay...
bei der ganzen Abgleicherei ist vor allem das Problem, Inkonsistenzen zu vermeiden, denke ich. Diese knnten beispielsweise auftauchen, wenn ich die aktuellen Daten aus der WaWi in dem shop importiere, aber vorher die Bestell-Mails nicht verarbeitet habe. Oder wenn ich Sachen verkaufe, die in der WaWi noch im Vorrat sind, waerend parallel jemand die letzten im phPay bestellt ..... Am sinnvollsten wre sicherlich eine gemeinsame Datenbasis fr beide Programme, was aber so ohne weiteres nicht mglich ist...
Ein Upload der Daten wre mittels scp schn automatisierbar, bzw. mit einer direkten Datenbankverindung zur Shop-Datenbank, was das lstige Importieren erspart.
Ein anderer Ansatz wre eine komplett getrennte Lagerverwaltung fr direkten Verkauf und online Verkauf ... wobei das auch wieder einiges an Mehraufwand bedeutet. Vorteil wre halt, da kein Abgleich stattfinden mu, und ich in jedem der beiden Systeme zu jedem Zeitpunkt genau wei, was vorrtig ist.
Gru,
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Erster Wermutstropfen: phPay vertrgst sich nicht wirklich mit Postgre. Da ist etwas 'Nacharbeit' ntig :-(
Die Bestellmails direkt auszuwerten ist ein gute Idee; aber da hren meine Kenntnisse auf. Ich bin aber dankbar fr Lsungen ;-)
Die Inkonsistenzen bei der Lagerhaltung sehe ich nicht so dramatisch. Deine Beschreibung ist natrlich richtig und nachvollziehbar. Wenn Du aber das 'Lager' des Shops nur als ein Kontingengt betrachtest und der Bestand der WaWi als magebend betrachtet wird, wird das alles einfacher ... Wichtig ist dann nur, da die Bestell-Emails direkt in die Warenwirtschaft eingepflegt werden. Oder Du bercksichtigst im Internet den Bestand berhaupt nicht. Das hngt ein bichen davon ab, was Du fr Waren hast. Bei Produkten, die definitiv irgendwann ausverkauft sind, ist das spannend, sonst nicht wirklich.
Kurzum: La die Sache mit dem Lagerbestand im Internet einfach ganz weg. Es ergeben sich zunchst noch genug andere Probleme.
Eine direkte Verbindung zur Datenbank wre super. Die meisten Provider bieten das jedoch nicht an. Wenn Du die Mglichkeit hastm solltest Du sie nutzen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
das mit Postgresql ist schade ... ich mag MySQL nicht wirklich... ausgehend von den Postings der letzten Zeit, hatte ich das Postgresql-Problem fr geklrt gehalten.
Fr die Auswertung der Bestellmails gbe es 2 Anstze, die in unterschiedlich komplexen Programmen enden.
Zum einen kann man das PHP-Script, was die Mails erzeugt so anpassen, da diese Mails schon in einem fr Maschinen besser lesbarem Format erstellt werden (CSV oder irgendsowas) das erleichtert das parsen ungemein erfordert aber nderungen am PHP. Andererseits kann man auch einfach die "Standard-Mails" auswerten, was einen intelligenteren Parser vorraussetzt, der damit grer, verzweigter, fehleranflliger und damit langsamer ist. Sprache meiner Wahl wre da Perl (gute Regex, Datenbankanbindung).
Den Warenbestand im Internet ganz wegzulassen, ich wei nicht. Auer sie tauchen im phPay gar nicht auf, sobald sie in der WaWi ausverkauft sind.
Nur ein bestimmtes Kontingent in phPay zu packen ist ja (fast) wie eine 2. Lagerhaltung. (angenommen ich habe 10000 Schrauben, von denen packe ich 4000 ins phPay, also bleiben mir 6000 zum anderweitigen Verkauf. Stecke ich die 4000 gar nicht erst in die WaWi, brauchen die beiden nicht kommunizieren, und ich habe getrennte "Lager" ... mit allen damit verbundenen Vor- und Nachteilen.)
Verbindung zur Datenbank bekomme ich ohne weiteres, wenn ich beim Hoster einen Server habe, auf dem ich root sein darf :-)
Gruss.
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ob MySQL oder PostgreSQL kann ich nicht beurteilen, da ich nur MySQL kenne und soweit zufrieden bin :-).
Wie schon erwhnt: Zum Thema automatiche Bestell-Email-Verarbeitung kann ich Dir nichts sagen ... Fr solche Aufgaben ist Perl eventuell besser geeignet als PHP, aber grundstzlich knnte auch PHP das. Funktioniert schlielich genau wie Perl auch an der Konsole (oder Eingabeaufforderung ;-)
Fehler knnen berall passieren. Wenn die zuverarbeitende Mail nicht richtig erstellt wird, kann auch ein einfacher Parser nix mehr retten. Ich denke, da ein Mittelweg das richtige ist. Im Shop die Mail maschinengerecht aufbereiten (z.B. Kunden-Id statt dem ganzen Namensgermpel, Artikel-Id usw.) Einer Maschine gengt so etwas vllig.
Gerade beim Artikel 'Schrauben' wrde ich sagen: Wozu einen Lagerbestand im Internet? So przise mu es dabei doch nicht zugehen oder? Schrauben M8 gab es vor zehn Jahren schon und wird es auch in zehn Jahren noch geben ... Wenn Du das Shop-Lager mit jedem Update an das WaWi-Lager anpat gengt das doch oder? Im Zweifelsfall hngt das Shoplager eben etwas hinterher ...
Im Rahmen des Shoplagers hast Du sowieso sowieso Schwierigkeiten mit Warenkrben, die erst befllt werden und dann nicht bestellt. Die Artikel sind dann zwar aus dem Shoplager entnommen, aber der Warenkorb 'herrenlos'. Es wre kein 100%iger Verla darauf ...
Insgesamt wird es wohl sehr schwer die Daten konsistent zu halten. Gerade, wenn Du anstrebst zwei verschiedene Systeme zusammenzubringen. Im Rahmen einiger Kundeauftrge bin ich jetzt soweit, wenigstens eine Bestellverwaltung erstellt zu haben (wre was fr den Thread 'user testen?'). Wenn ich mir vorstelle, da auch noch den Rest der Warenwirtschaft anzuhngen ... Ebenso wird es jemandem mit einem Shop gehen, der eine Warenwirtschaft entwickelt hat.
Fr die Przision, die Du zu erwarten scheinst, kommst Du um eine einheitliche Datenbank nicht drumrum. Ansonsten bleiben Dir immer die Zeitrume zwischen den Updates, die fr Unsicherheit sorgen. Und wenn Du die Abstnde sehr kurz whltst, kommst Du kostenmig auch auf eine Standleitung raus (wenn nicht teurer) oder bei groen Datenmengen berholen sich die Updates gegenseitig ...
Der schon beschriebene Hardware-Hndler aktualisiert seinen Internetbestand alle 15min. Der im Internet angezeigte Bestand wird nur im WaWi gepflegt. Wenn also Vor-Ort etwas verkauft wird, kommt es genau zu der von Dir beschreibenen Inkonsistenz.
Was Du bei einer direkten Verbindung zu Deiner Datenbank auch noch bedenken solltest, ist die Sicherheit. Aber das ist wieder ein ganz anderes Thema und mindestens so ergiebig.
Gru,
Andreas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unterschied Postgres und MySQL: das eine ist eine Datenbank, das andere ein Karteikartensystem ,-)
Die automatische eMail-Verarbeitung ist fr mich kein Problem zu schreiben, wollte nur das allgemeine Vorgehen hier mal dargelegt haben, falls es Dich oder jemand anderes interessiert. Wird die eMail auf dem Server nicht richtig erstellt, habe ich als menschlicher Parser auch meine Probleme, und kann die Bestellung nicht korrekt ausfhren. Programmieren kann ich den Spass selber, es geht hier lediglich um konzeptionelle Denkanstoesse und eventuelle Tips anderer Nutzer, um nicht das Rad doppelt erfinden zu mssen.
Moment, hab ich Dich richtig verstanden, dass man daraus einen DoS machen kann, indem man einfach Warenkrbe fllt und nicht bestellt? Also irgendwann ist mein Lager leer, keiner kann mehr was bestellen, und ich habe nichts verkauft?? Wenn das wirklich so ist, ist die gesamte Funktionalitt sinnfrei.
Ich habe gesehen, Du machst die Warenkorbverwaltung ber PHPSessionIDs, laufen die irgendwann mal aus, oder sowas? Wenn, dann koennte man diese Sache noch mit Transaktionen retten (also einfach ein ROLLBACK, wenn die Session ausluft und nichts bestellt ist). Eine weitere Mglichkeit wre, die Stckzahl in der Datenbank erst zu verringern, wenn eine Bestell-eMail rausgeht, hat aber genau das umgekehrte Problem zur Folge, nmlich da der Bestand immer voll aussieht, und parallel einkaufende Leute mehr kaufen knnen, als da ist.
Ergo ist eine genaue Stckzahl an Artikeln in der Shop-Datenbank nicht (zu jedem Zeitpunkt) zu erwarten.
Ich werde einfach mal abklren, wie wichtig eine genaue Lagerhaltung im OnlineShop ist, und dann entsprechend weitersehen.
Gru,
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Deine Aussage in der ersten Zeile ist eine, wie ich sie berhaupt nicht leiden kann; weder in Diskussionen um Betriebsysteme, noch um Browser oder sonst irgendwas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
das mit Postgresql ist schade ... ich mag MySQL nicht wirklich... ausgehend von den Postings der letzten Zeit, hatte ich das Postgresql-Problem fr geklrt gehalten.
Fr die Auswertung der Bestellmails gbe es 2 Anstze, die in unterschiedlich komplexen Programmen enden.
Zum einen kann man das PHP-Script, was die Mails erzeugt so anpassen, da diese Mails schon in einem fr Maschinen besser lesbarem Format erstellt werden (CSV oder irgendsowas) das erleichtert das parsen ungemein erfordert aber nderungen am PHP. Andererseits kann man auch einfach die "Standard-Mails" auswerten, was einen intelligenteren Parser vorraussetzt, der damit grer, verzweigter, fehleranflliger und damit langsamer ist. Sprache meiner Wahl wre da Perl (gute Regex, Datenbankanbindung).
Den Warenbestand im Internet ganz wegzulassen, ich wei nicht. Auer sie tauchen im phPay gar nicht auf, sobald sie in der WaWi ausverkauft sind.
Nur ein bestimmtes Kontingent in phPay zu packen ist ja (fast) wie eine 2. Lagerhaltung. (angenommen ich habe 10000 Schrauben, von denen packe ich 4000 ins phPay, also bleiben mir 6000 zum anderweitigen Verkauf. Stecke ich die 4000 gar nicht erst in die WaWi, brauchen die beiden nicht kommunizieren, und ich habe getrennte "Lager" ... mit allen damit verbundenen Vor- und Nachteilen.)
Verbindung zur Datenbank bekomme ich ohne weiteres, wenn ich beim Hoster einen Server habe, auf dem ich root sein darf :-)
Gruss.
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, kurze Anmerkung. Wenn man solch eine komplexe Lsung sucht und auch wirklich haben will wird man an der Suche auch auf dem kommerziellen Markt nicht herumkommen. Evtl. weitest Du Deine Suche gleich noch in Richtung Versanduntersttzung aus, sonst hast Du da das nchste Problem. Ich habe so etwas mal als Logistikkreis bezeichnet und habe einige Kunden die eben nicht nur einen Shop brauchen, sondern einen Kreis (www.logistik11.de).
Anmerkung zum angemieteten Server. Aus meiner Sicht ist eine SSL Verschlsselung unumgnglich, da sonst jemand die SessionID"klauen" kann ! Wenn man dies mit einem 1und1 ExclusiveServer macht hat man SSL (http://ssl.kundenserver.de/blafasel.com/) dabei und keinen externen Zugriff auf die Datenbank.
Denkt man an einen RootServer oder vserver hat man erstmal kein SSL, aber direkten Datenbankzugang.
Bei uns ist es so die Warenwirtschaft ist das fhrende System, Kundennnummern werden in einem eigenen Nummerkreis auf dem Shop auch erstellt. Aber Rechnung/AB etc. alles nur in der WaWi.
Welche WaWi's betrachtest Du derzeit ?
Lutz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, betreffend Warenwirtschaft wre es sinnvoll, wenn jeder mal schreiben wrde, welche er/sie verwendet und welche Erfahrungen damit gemacht wurden. Eine open source Lsung wre einem kommerziellen Produkt evtl. vorzuziehen, weil man eine Schnittstelle zu phpay leichter herstellen knnte und auch die Anschaffungskosten sparen knnte. Ich fnde es gut wenn wir ein Produkt finden knnten was passt und dann eine Anbindung an phpay programmieren wrden.
Betreffen Provider kann ich http://www.power-netz.de/ empfehlen. Gnstig,schnell und fast 100% Erreichbarkeit. Bin in 3 Jahren noch nicht einmal enttuscht worden.
Gru
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wenn ich Lutz richtig verstanden habe, sollte der Shop dem WaWi nach-/untergeordnet sein. Dem wrde ich zustimmen, weil bei einer WaWi ja noch ewig viele Dinge dazukommen bis hin zum Onlinebanking. Die meisten der Dinge laufen dann im Intranet.
Ich persnlich habe noch keine WaWi, berlege mir allerdings auf Basis von phPay ein Offline-Tool zu bauen; mit PHP-GTK sollte das mglich sein. Wahrscheinlich sind die Ansprche an eine WaWi aber sehr unterschiedlich.
Was ich mir so an Funktionalitt vorstelle:
- Bestellverwaltung: Datum, Status, Bemerkungen, Rechnungsdatum, Mahn-Dingsbums
- Rechnungen speichern (vielleicht als PDF; http://fpdf.org ;-)
- Lagerbestand verwalten
- Auswertungen fr Zahlungseingnge/-ausgnge, so da ich am Ende eines Monats fr den Steuerberater Buchungen ausdrucken kann (Rechngs.Nr, Betrag, Grund, ...)
Die ersten drei Punkte sind fr meinen Bedarf weitestgehend in der Datenbankstruktur von phPay enthalten. Der letzte Punkt und auch die Mahngeschichte macht mir etwas Sorgen. Ebenso wie GTK ;-)
Gru,
Andreas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kleiner Nachtrag noch zu Ansprchen:
- Schick wre, wenn man auch 'Angebote' erstellen und speichern knnte.
- eine ordentliche Druckfunktion (das ist ja nu im Browser nicht der Knaller ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi erstmal, also ich habe unsere (selbst entwickelte) Warenwirtschaft mit dem Shop verbunden. Ich hab das ganze so gelst. Da unsere Webserver direkt im Haus an ner Standleitung hngen war das ganze ziemlich einfach. Die Warenwirtschaft schickt via ODBC laufend genderte Daten direkt in die mySQL Datenbanken des Shops.Somit ist der eine Weg schonmal klar. Desweiteren habe ich die Mails vom Shop so verndert, da ich sie mit einem 2. Programm ohne weiteres empfangen und Auswerten kann. Die Mail wird dann "auseinander"genommen und daraus wird ein Lieferschein generiert, der dann gedruckt und gepackt wird. Jetzt nur noch alles verschicken und fertig ist das ganze :-)
mfg Jarno
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cool.
Wrdest Du die 'Mailverarbeitung' der Allgemeinheit zur Verfgung stellen?
Welche WaWi verwendest Du? Oder liee sich der Export auch fr andere verwenden?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, also ich habe den Shop als Bestellsystem fr einen Brobedarfsgrohandel genommen. Deswegen drfte das Programm nicht so interessant sein. Aber ich kann natrlich das ganze so ndern, da vielleicht irgendwas anderes dabei rauskommt. Die Warenwirtschaft ist selber in Delphi Programmiert. Dahinter hngt eine Interbase Datenbank und die ist dann ber die Programme mit dem Shop verknpft. Ach ja welche Mailverarbeitung meinst du? Das Delphi Programm oder die genderte mailer.inc.php? Letztendlich habe ich einfach nur die Kundennummer, die Artikelnummer und die Menge mit Semikolon getrennt als Mail versendet. Die Preise und den Rest hab ich ja hier im Haus :-)
ciao Jarno
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Klingt insgesam sehr speziell ... vielleicht liee sich Deine Variante ja insofern verallgemeinern, da man wenigstens per ODBC Daten an phPay's-MySQL schicken kann?
Dann knnten andere Menschen dies als Schnittstelle fr ihre eigene WaWi benutzen ... ist nur so'ne Idee. Dann wre zumindest die Problematik WaWi->phPay schon mal gelst.
Gibt es WaWi-Benutzer, die sich eine derartige Nutzung vorstellen knnten?
Die Gegenrichtung ist wegen der verschiedenen WaWi-System natrlich schwieriger ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Klingt insgesam sehr speziell ... vielleicht liee sich Deine Variante ja insofern verallgemeinern, da man wenigstens per ODBC Daten an phPay's-MySQL schicken kann?
Dann knnten andere Menschen dies als Schnittstelle fr ihre eigene WaWi benutzen ... ist nur so'ne Idee. Dann wre zumindest die Problematik WaWi->phPay schon mal gelst.
Gibt es WaWi-Benutzer, die sich eine derartige Nutzung vorstellen knnten?
Die Gegenrichtung ist wegen der verschiedenen WaWi-System natrlich schwieriger ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ja stimmt, ich habe etliches vom phPay verndert, damit das ganze zusammenarbeitet. Hmm man msste irgende offene mglichkeit schaffen um von einer beliebigen Datenbank die Daten via ODBC an mySQL verschicken zu knnen *grbel* Dummerweise ist das ganze dann schon wieder hinfllig, wenn der Server nicht im Haus steht. Oder welcher Provider lsst den Port 3306 offen? Na mal schauen, ich versuche mir mal was zu berlegen und wenn ich es habe, stelleich es hier rein :-)
PS. Wenn die WaWis ne halbwegs gleiche Importschnittstelle htten wre die andere Richtung auch einfach :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So ich hab mich jetzt mal ne Weile mit der Problematik befasst. Aber irgendwie komme ich nicht zu einem Vernnftigen Ergebnis. Wenn man selber die Firewall konfigurieren kann und somit zugriff auf den Port von mySQL hat (also die 3306) klappt alles Prima. Aber leider lassen die Provider keinen direkten zugriff zu :-( Ich bekomme einfach keinen Connect hin. Also so richtig weis ich nun auch nicht weiter, wie man das ganze machen soll.
Jarno
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Selber Provider spielen und mit fester, ffentlicher IP arbeiten ;-) Ist natrlich eine Preisfrage. DynDNS und DSL ist wahrscheinlich auch nicht der Knaller, sind aber immerhin Alternativen ...
Letztlich ist ein Import zu phPay folgender Vorgang:
- Export der Daten aus einer anderen Anwendung als CSV-Datei
- Browser auf, Import von phPay, HTTP-Upload.
Wre denn folgendes praktikabel:
a) Export wie gehabt
b) Upload der CSV-Datei per FTP
c) Link aufrufen, der einen Import mit der hochgeladenen Datei startet
zu b) Manche FTP-Programme knnen zeitgesteuert eine Verbindung aufbauen und Dateien hochladen. Mein Hardware-Hndler aktualisiert seinen Shop genau so.
zu c) Den Teil gibt es freilich noch nicht. Die PHP-Datei mte halt statt einer is_uploaded()-Datei mit einer bestimmten arbeiten; Dateiname/-pfad wre also fest vorgegeben.
Also etwa:
Zeile 3 von admin/importitem*:
if (file_exists("./import/$datafile") && $datafile!="") {
Jetzt mu nur noch die CSV automatisch generiert werden - aber das ist nicht mehr wirklich mein Problem ;-) Mit einem Cron-Job oder dem Taskplaner sollte sich das aber machen lassen.
Gru,
Andreas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, das mit der festenIP und nem eigenen Server wre natrlich der Idealfall. Sohaben wir esja auch im Einsatz. Ist allerdings auch ein wenig teurer als eine normale Flatrate.Also das mit dem Zeitgesteuerten FTP Transfer ist kein Problem. Die bertragung so zu gestalten wre auch einfach. Das einzige Problem istnun nur noch, da auch alle WWS einen Export der Daten anbieten ;-) Naja das ist eher Grundvorraussetzung fr das ganze berhaupt. Ich bastele mal so ein Proggi zusammen undstelle es hier zur verfgung. Dann knnt ihr das ganze mal probieren.
Gru
Jarno
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
ich habe mich heute nach einigen freien Warenwirtschafts-Systemen umgesehen, und die Frage kam auf, ob und wenn mit welchen, eine mglichst reibungslose phPay Einbindung mglich wre.
Stndiges Im-/Exportieren ist nicht wirklich praktikabel, zumal Artikel aus dem Warenbestand auch auerhalb des Internets bzw. dieses einen Shops vertrieben werden sollen, und eine doppelte Transaktionsabwicklung nicht wirklich zeitsparend und bersichtlich ist, vor allem wenn man nicht extra jemanden fr die Buchhaltung einstellen will/kann.
Mich wrde einmal interessieren, wie andere diese Probleme gelst haben.
Danke fr Eure Tips.
PS: sorry fr das doppelte Posting, aber mir ist irgendwie erst auf den zweiten Blick aufgefallen, da das Posting in diesem Forum wohl besser aufgehoben sein wird :-)
Kannst Du Deine Vorstellungen der Anbindung przisieren? Fragen die fr mich noch offen sind:
- Wie soll ein Abgleich stattfinden?
a) nur Daten von WW(Warenwirtschaft) -> phPay
b) WW <-> phPay
c) Bestellungen phPay -> WW
- Was fr eine Rechnerumgebung hast Du?
Die Schwierigkeit ist vorallem, da der Webserver, auf dem phPay (oder sonst irgendeine Shopsystem) werkelt, nicht selbst aktiv wird, sondern immer nur Anfragen bearbeitet. Von naturaus wird der Webserver also nicht irgendwelche Importroutinen aufrufen. Das liee sich aber noch entweder ber Cronjobs (einige Provider bieten das an) oder den Taskplaner lsen (1).
Zweites Problem: Wie kommen die aktuellen Daten zum phPay-Webserver. Vielleicht per automatisiertem FTP-Upload (2)?
Was kann Deine WW? Mut Du dort aktiv werden, um Artikel zu exportieren; erfolgt das automatisch nach jeder nderung(3)?
Mein Hardware-Hndler macht das so: Aus seiner Warenwirtschaft werden alle 15min Daten ausgelesen und in eine Textdatei geschrieben(3). Diese Textdatei wird per FTP automatisch hochgeladen (2) und dann verarbeitet (1).
Im Sinne von phPay knnte das hnlich ablaufen. Die Textdatei wre eine CSV-Datei, die Deine Warenwirtschaft produziert (3). Automatischer Upload ist nur eine Sache Software. Von WSftp, wei ich da es funktioniert. Auch andere FTP-Programme werden das knnen, auch unter Nicht-Windows. Auf irgendeine Weise mu dann nur noch eine leicht modifizierte importitem.inc.php aufgerufen werden, die eben direkt auf die zu importierende Datei zugreift und keine erwartet, die per HTTP hochgeladen wurde.
Die ganz andere Variante ist: WW und phPay laufen auf der gleichen Maschine. Dann kann die WW direkt in phPays Datenbank schreiben :-) Das ist sicher das eleganteste und schnste. Aus phPay-Sicht will einfacher. Dafr sind dann andere Gegebenheiten wichtig: Anbindung, Hardware usw...
Weiterer Vorschlag: Die WW bernimmt den automatischen Upload nachdem sie die Daten exportiert hat und ruft dann die entsprechende Webseite des Shops auf.
Gru,
Andreas.
danke fr Deine umfangreiche Antwort. Eine Mailingliste statt des Forums wrde Diskussionen erheblich vereinfachen, da man da ordentlich Quoten kann und richtige Threads hat :-)
Zu Deinen Fragen:
es sollte ein bidirektionaler Abgleich stattfinden, also WW<->phpay, da ja in beiden "Welten" Artikel verkauft werden, die von einem gemeinsamen Lagerbestand abgehen.
Als Rechnerumgebung wird ein Linux zum Einsatz kommen. das phpay wird auf einem dedizierten Server bei einem Provider laufen, auf dem ich vollen root-Zugriff via ssh etc. habe. Als Datenbank wird Postgresql eingesetzt werden, da bisher laufende Lsungen diese auch schon nutzen.
Eine Wahl zum Thema WaWi-Software ist noch nicht getroffen, das wird davon abhngen wie (gut) sie sich mit externer Software verbinden lt. Eine kommerzielle WaWi wird nicht angestrebt, da ich Wert auf die eigene Erweiterbarkeit einer unter GPL stehenden Software lege, was allerdings die Auswahl erheblich einschrnkt ;-(
Da am Arbeitsplatz keine Flatrate mglich ist, wird die WaWi wohl nicht auf der gleichen Maschine laufen knnen, wie der Shop, was den Abgleich erschwert.
Mglicher Ansatz der mir bisher eingefallen ist:
- Kunde bestellt im phPay
- mail wird generiert
- fetchmail holt mails ... procmail stellt fest, dass es sich um eine Bestellung handelt und bergibt die Mail an einen Parser.
- der parser nimmt die Bestellung dann auseinander und pflegt sie in die Datenbank der WaWi ein.
damit htte man schonmal eine Synchronisierung phPay->WW
fehlt nur noch der Weg WW->phPay...
bei der ganzen Abgleicherei ist vor allem das Problem, Inkonsistenzen zu vermeiden, denke ich. Diese knnten beispielsweise auftauchen, wenn ich die aktuellen Daten aus der WaWi in dem shop importiere, aber vorher die Bestell-Mails nicht verarbeitet habe. Oder wenn ich Sachen verkaufe, die in der WaWi noch im Vorrat sind, waerend parallel jemand die letzten im phPay bestellt ..... Am sinnvollsten wre sicherlich eine gemeinsame Datenbasis fr beide Programme, was aber so ohne weiteres nicht mglich ist...
Ein Upload der Daten wre mittels scp schn automatisierbar, bzw. mit einer direkten Datenbankverindung zur Shop-Datenbank, was das lstige Importieren erspart.
Ein anderer Ansatz wre eine komplett getrennte Lagerverwaltung fr direkten Verkauf und online Verkauf ... wobei das auch wieder einiges an Mehraufwand bedeutet. Vorteil wre halt, da kein Abgleich stattfinden mu, und ich in jedem der beiden Systeme zu jedem Zeitpunkt genau wei, was vorrtig ist.
Gru,
Christian
Erster Wermutstropfen: phPay vertrgst sich nicht wirklich mit Postgre. Da ist etwas 'Nacharbeit' ntig :-(
Die Bestellmails direkt auszuwerten ist ein gute Idee; aber da hren meine Kenntnisse auf. Ich bin aber dankbar fr Lsungen ;-)
Die Inkonsistenzen bei der Lagerhaltung sehe ich nicht so dramatisch. Deine Beschreibung ist natrlich richtig und nachvollziehbar. Wenn Du aber das 'Lager' des Shops nur als ein Kontingengt betrachtest und der Bestand der WaWi als magebend betrachtet wird, wird das alles einfacher ... Wichtig ist dann nur, da die Bestell-Emails direkt in die Warenwirtschaft eingepflegt werden. Oder Du bercksichtigst im Internet den Bestand berhaupt nicht. Das hngt ein bichen davon ab, was Du fr Waren hast. Bei Produkten, die definitiv irgendwann ausverkauft sind, ist das spannend, sonst nicht wirklich.
Kurzum: La die Sache mit dem Lagerbestand im Internet einfach ganz weg. Es ergeben sich zunchst noch genug andere Probleme.
Eine direkte Verbindung zur Datenbank wre super. Die meisten Provider bieten das jedoch nicht an. Wenn Du die Mglichkeit hastm solltest Du sie nutzen.
das mit Postgresql ist schade ... ich mag MySQL nicht wirklich... ausgehend von den Postings der letzten Zeit, hatte ich das Postgresql-Problem fr geklrt gehalten.
Fr die Auswertung der Bestellmails gbe es 2 Anstze, die in unterschiedlich komplexen Programmen enden.
Zum einen kann man das PHP-Script, was die Mails erzeugt so anpassen, da diese Mails schon in einem fr Maschinen besser lesbarem Format erstellt werden (CSV oder irgendsowas) das erleichtert das parsen ungemein erfordert aber nderungen am PHP. Andererseits kann man auch einfach die "Standard-Mails" auswerten, was einen intelligenteren Parser vorraussetzt, der damit grer, verzweigter, fehleranflliger und damit langsamer ist. Sprache meiner Wahl wre da Perl (gute Regex, Datenbankanbindung).
Den Warenbestand im Internet ganz wegzulassen, ich wei nicht. Auer sie tauchen im phPay gar nicht auf, sobald sie in der WaWi ausverkauft sind.
Nur ein bestimmtes Kontingent in phPay zu packen ist ja (fast) wie eine 2. Lagerhaltung. (angenommen ich habe 10000 Schrauben, von denen packe ich 4000 ins phPay, also bleiben mir 6000 zum anderweitigen Verkauf. Stecke ich die 4000 gar nicht erst in die WaWi, brauchen die beiden nicht kommunizieren, und ich habe getrennte "Lager" ... mit allen damit verbundenen Vor- und Nachteilen.)
Verbindung zur Datenbank bekomme ich ohne weiteres, wenn ich beim Hoster einen Server habe, auf dem ich root sein darf :-)
Gruss.
Christian
Ob MySQL oder PostgreSQL kann ich nicht beurteilen, da ich nur MySQL kenne und soweit zufrieden bin :-).
Wie schon erwhnt: Zum Thema automatiche Bestell-Email-Verarbeitung kann ich Dir nichts sagen ... Fr solche Aufgaben ist Perl eventuell besser geeignet als PHP, aber grundstzlich knnte auch PHP das. Funktioniert schlielich genau wie Perl auch an der Konsole (oder Eingabeaufforderung ;-)
Fehler knnen berall passieren. Wenn die zuverarbeitende Mail nicht richtig erstellt wird, kann auch ein einfacher Parser nix mehr retten. Ich denke, da ein Mittelweg das richtige ist. Im Shop die Mail maschinengerecht aufbereiten (z.B. Kunden-Id statt dem ganzen Namensgermpel, Artikel-Id usw.) Einer Maschine gengt so etwas vllig.
Gerade beim Artikel 'Schrauben' wrde ich sagen: Wozu einen Lagerbestand im Internet? So przise mu es dabei doch nicht zugehen oder? Schrauben M8 gab es vor zehn Jahren schon und wird es auch in zehn Jahren noch geben ... Wenn Du das Shop-Lager mit jedem Update an das WaWi-Lager anpat gengt das doch oder? Im Zweifelsfall hngt das Shoplager eben etwas hinterher ...
Im Rahmen des Shoplagers hast Du sowieso sowieso Schwierigkeiten mit Warenkrben, die erst befllt werden und dann nicht bestellt. Die Artikel sind dann zwar aus dem Shoplager entnommen, aber der Warenkorb 'herrenlos'. Es wre kein 100%iger Verla darauf ...
Insgesamt wird es wohl sehr schwer die Daten konsistent zu halten. Gerade, wenn Du anstrebst zwei verschiedene Systeme zusammenzubringen. Im Rahmen einiger Kundeauftrge bin ich jetzt soweit, wenigstens eine Bestellverwaltung erstellt zu haben (wre was fr den Thread 'user testen?'). Wenn ich mir vorstelle, da auch noch den Rest der Warenwirtschaft anzuhngen ... Ebenso wird es jemandem mit einem Shop gehen, der eine Warenwirtschaft entwickelt hat.
Fr die Przision, die Du zu erwarten scheinst, kommst Du um eine einheitliche Datenbank nicht drumrum. Ansonsten bleiben Dir immer die Zeitrume zwischen den Updates, die fr Unsicherheit sorgen. Und wenn Du die Abstnde sehr kurz whltst, kommst Du kostenmig auch auf eine Standleitung raus (wenn nicht teurer) oder bei groen Datenmengen berholen sich die Updates gegenseitig ...
Der schon beschriebene Hardware-Hndler aktualisiert seinen Internetbestand alle 15min. Der im Internet angezeigte Bestand wird nur im WaWi gepflegt. Wenn also Vor-Ort etwas verkauft wird, kommt es genau zu der von Dir beschreibenen Inkonsistenz.
Was Du bei einer direkten Verbindung zu Deiner Datenbank auch noch bedenken solltest, ist die Sicherheit. Aber das ist wieder ein ganz anderes Thema und mindestens so ergiebig.
Gru,
Andreas.
Unterschied Postgres und MySQL: das eine ist eine Datenbank, das andere ein Karteikartensystem ,-)
Die automatische eMail-Verarbeitung ist fr mich kein Problem zu schreiben, wollte nur das allgemeine Vorgehen hier mal dargelegt haben, falls es Dich oder jemand anderes interessiert. Wird die eMail auf dem Server nicht richtig erstellt, habe ich als menschlicher Parser auch meine Probleme, und kann die Bestellung nicht korrekt ausfhren. Programmieren kann ich den Spass selber, es geht hier lediglich um konzeptionelle Denkanstoesse und eventuelle Tips anderer Nutzer, um nicht das Rad doppelt erfinden zu mssen.
Moment, hab ich Dich richtig verstanden, dass man daraus einen DoS machen kann, indem man einfach Warenkrbe fllt und nicht bestellt? Also irgendwann ist mein Lager leer, keiner kann mehr was bestellen, und ich habe nichts verkauft?? Wenn das wirklich so ist, ist die gesamte Funktionalitt sinnfrei.
Ich habe gesehen, Du machst die Warenkorbverwaltung ber PHPSessionIDs, laufen die irgendwann mal aus, oder sowas? Wenn, dann koennte man diese Sache noch mit Transaktionen retten (also einfach ein ROLLBACK, wenn die Session ausluft und nichts bestellt ist). Eine weitere Mglichkeit wre, die Stckzahl in der Datenbank erst zu verringern, wenn eine Bestell-eMail rausgeht, hat aber genau das umgekehrte Problem zur Folge, nmlich da der Bestand immer voll aussieht, und parallel einkaufende Leute mehr kaufen knnen, als da ist.
Ergo ist eine genaue Stckzahl an Artikeln in der Shop-Datenbank nicht (zu jedem Zeitpunkt) zu erwarten.
Ich werde einfach mal abklren, wie wichtig eine genaue Lagerhaltung im OnlineShop ist, und dann entsprechend weitersehen.
Gru,
Christian
Deine Aussage in der ersten Zeile ist eine, wie ich sie berhaupt nicht leiden kann; weder in Diskussionen um Betriebsysteme, noch um Browser oder sonst irgendwas.
das mit Postgresql ist schade ... ich mag MySQL nicht wirklich... ausgehend von den Postings der letzten Zeit, hatte ich das Postgresql-Problem fr geklrt gehalten.
Fr die Auswertung der Bestellmails gbe es 2 Anstze, die in unterschiedlich komplexen Programmen enden.
Zum einen kann man das PHP-Script, was die Mails erzeugt so anpassen, da diese Mails schon in einem fr Maschinen besser lesbarem Format erstellt werden (CSV oder irgendsowas) das erleichtert das parsen ungemein erfordert aber nderungen am PHP. Andererseits kann man auch einfach die "Standard-Mails" auswerten, was einen intelligenteren Parser vorraussetzt, der damit grer, verzweigter, fehleranflliger und damit langsamer ist. Sprache meiner Wahl wre da Perl (gute Regex, Datenbankanbindung).
Den Warenbestand im Internet ganz wegzulassen, ich wei nicht. Auer sie tauchen im phPay gar nicht auf, sobald sie in der WaWi ausverkauft sind.
Nur ein bestimmtes Kontingent in phPay zu packen ist ja (fast) wie eine 2. Lagerhaltung. (angenommen ich habe 10000 Schrauben, von denen packe ich 4000 ins phPay, also bleiben mir 6000 zum anderweitigen Verkauf. Stecke ich die 4000 gar nicht erst in die WaWi, brauchen die beiden nicht kommunizieren, und ich habe getrennte "Lager" ... mit allen damit verbundenen Vor- und Nachteilen.)
Verbindung zur Datenbank bekomme ich ohne weiteres, wenn ich beim Hoster einen Server habe, auf dem ich root sein darf :-)
Gruss.
Christian
Hi, kurze Anmerkung. Wenn man solch eine komplexe Lsung sucht und auch wirklich haben will wird man an der Suche auch auf dem kommerziellen Markt nicht herumkommen. Evtl. weitest Du Deine Suche gleich noch in Richtung Versanduntersttzung aus, sonst hast Du da das nchste Problem. Ich habe so etwas mal als Logistikkreis bezeichnet und habe einige Kunden die eben nicht nur einen Shop brauchen, sondern einen Kreis (www.logistik11.de).
Anmerkung zum angemieteten Server. Aus meiner Sicht ist eine SSL Verschlsselung unumgnglich, da sonst jemand die SessionID"klauen" kann ! Wenn man dies mit einem 1und1 ExclusiveServer macht hat man SSL (http://ssl.kundenserver.de/blafasel.com/) dabei und keinen externen Zugriff auf die Datenbank.
Denkt man an einen RootServer oder vserver hat man erstmal kein SSL, aber direkten Datenbankzugang.
Bei uns ist es so die Warenwirtschaft ist das fhrende System, Kundennnummern werden in einem eigenen Nummerkreis auf dem Shop auch erstellt. Aber Rechnung/AB etc. alles nur in der WaWi.
Welche WaWi's betrachtest Du derzeit ?
Lutz
Hi, betreffend Warenwirtschaft wre es sinnvoll, wenn jeder mal schreiben wrde, welche er/sie verwendet und welche Erfahrungen damit gemacht wurden. Eine open source Lsung wre einem kommerziellen Produkt evtl. vorzuziehen, weil man eine Schnittstelle zu phpay leichter herstellen knnte und auch die Anschaffungskosten sparen knnte. Ich fnde es gut wenn wir ein Produkt finden knnten was passt und dann eine Anbindung an phpay programmieren wrden.
Betreffen Provider kann ich http://www.power-netz.de/ empfehlen. Gnstig,schnell und fast 100% Erreichbarkeit. Bin in 3 Jahren noch nicht einmal enttuscht worden.
Gru
Peter
Wenn ich Lutz richtig verstanden habe, sollte der Shop dem WaWi nach-/untergeordnet sein. Dem wrde ich zustimmen, weil bei einer WaWi ja noch ewig viele Dinge dazukommen bis hin zum Onlinebanking. Die meisten der Dinge laufen dann im Intranet.
Ich persnlich habe noch keine WaWi, berlege mir allerdings auf Basis von phPay ein Offline-Tool zu bauen; mit PHP-GTK sollte das mglich sein. Wahrscheinlich sind die Ansprche an eine WaWi aber sehr unterschiedlich.
Was ich mir so an Funktionalitt vorstelle:
- Bestellverwaltung: Datum, Status, Bemerkungen, Rechnungsdatum, Mahn-Dingsbums
- Rechnungen speichern (vielleicht als PDF; http://fpdf.org ;-)
- Lagerbestand verwalten
- Auswertungen fr Zahlungseingnge/-ausgnge, so da ich am Ende eines Monats fr den Steuerberater Buchungen ausdrucken kann (Rechngs.Nr, Betrag, Grund, ...)
Die ersten drei Punkte sind fr meinen Bedarf weitestgehend in der Datenbankstruktur von phPay enthalten. Der letzte Punkt und auch die Mahngeschichte macht mir etwas Sorgen. Ebenso wie GTK ;-)
Gru,
Andreas.
Kleiner Nachtrag noch zu Ansprchen:
- Schick wre, wenn man auch 'Angebote' erstellen und speichern knnte.
- eine ordentliche Druckfunktion (das ist ja nu im Browser nicht der Knaller ;-)
Hi erstmal, also ich habe unsere (selbst entwickelte) Warenwirtschaft mit dem Shop verbunden. Ich hab das ganze so gelst. Da unsere Webserver direkt im Haus an ner Standleitung hngen war das ganze ziemlich einfach. Die Warenwirtschaft schickt via ODBC laufend genderte Daten direkt in die mySQL Datenbanken des Shops.Somit ist der eine Weg schonmal klar. Desweiteren habe ich die Mails vom Shop so verndert, da ich sie mit einem 2. Programm ohne weiteres empfangen und Auswerten kann. Die Mail wird dann "auseinander"genommen und daraus wird ein Lieferschein generiert, der dann gedruckt und gepackt wird. Jetzt nur noch alles verschicken und fertig ist das ganze :-)
mfg Jarno
Cool.
Wrdest Du die 'Mailverarbeitung' der Allgemeinheit zur Verfgung stellen?
Welche WaWi verwendest Du? Oder liee sich der Export auch fr andere verwenden?
Hi, also ich habe den Shop als Bestellsystem fr einen Brobedarfsgrohandel genommen. Deswegen drfte das Programm nicht so interessant sein. Aber ich kann natrlich das ganze so ndern, da vielleicht irgendwas anderes dabei rauskommt. Die Warenwirtschaft ist selber in Delphi Programmiert. Dahinter hngt eine Interbase Datenbank und die ist dann ber die Programme mit dem Shop verknpft. Ach ja welche Mailverarbeitung meinst du? Das Delphi Programm oder die genderte mailer.inc.php? Letztendlich habe ich einfach nur die Kundennummer, die Artikelnummer und die Menge mit Semikolon getrennt als Mail versendet. Die Preise und den Rest hab ich ja hier im Haus :-)
ciao Jarno
Klingt insgesam sehr speziell ... vielleicht liee sich Deine Variante ja insofern verallgemeinern, da man wenigstens per ODBC Daten an phPay's-MySQL schicken kann?
Dann knnten andere Menschen dies als Schnittstelle fr ihre eigene WaWi benutzen ... ist nur so'ne Idee. Dann wre zumindest die Problematik WaWi->phPay schon mal gelst.
Gibt es WaWi-Benutzer, die sich eine derartige Nutzung vorstellen knnten?
Die Gegenrichtung ist wegen der verschiedenen WaWi-System natrlich schwieriger ...
Klingt insgesam sehr speziell ... vielleicht liee sich Deine Variante ja insofern verallgemeinern, da man wenigstens per ODBC Daten an phPay's-MySQL schicken kann?
Dann knnten andere Menschen dies als Schnittstelle fr ihre eigene WaWi benutzen ... ist nur so'ne Idee. Dann wre zumindest die Problematik WaWi->phPay schon mal gelst.
Gibt es WaWi-Benutzer, die sich eine derartige Nutzung vorstellen knnten?
Die Gegenrichtung ist wegen der verschiedenen WaWi-System natrlich schwieriger ...
Ja stimmt, ich habe etliches vom phPay verndert, damit das ganze zusammenarbeitet. Hmm man msste irgende offene mglichkeit schaffen um von einer beliebigen Datenbank die Daten via ODBC an mySQL verschicken zu knnen *grbel* Dummerweise ist das ganze dann schon wieder hinfllig, wenn der Server nicht im Haus steht. Oder welcher Provider lsst den Port 3306 offen? Na mal schauen, ich versuche mir mal was zu berlegen und wenn ich es habe, stelleich es hier rein :-)
PS. Wenn die WaWis ne halbwegs gleiche Importschnittstelle htten wre die andere Richtung auch einfach :-)
So ich hab mich jetzt mal ne Weile mit der Problematik befasst. Aber irgendwie komme ich nicht zu einem Vernnftigen Ergebnis. Wenn man selber die Firewall konfigurieren kann und somit zugriff auf den Port von mySQL hat (also die 3306) klappt alles Prima. Aber leider lassen die Provider keinen direkten zugriff zu :-( Ich bekomme einfach keinen Connect hin. Also so richtig weis ich nun auch nicht weiter, wie man das ganze machen soll.
Jarno
Selber Provider spielen und mit fester, ffentlicher IP arbeiten ;-) Ist natrlich eine Preisfrage. DynDNS und DSL ist wahrscheinlich auch nicht der Knaller, sind aber immerhin Alternativen ...
Letztlich ist ein Import zu phPay folgender Vorgang:
- Export der Daten aus einer anderen Anwendung als CSV-Datei
- Browser auf, Import von phPay, HTTP-Upload.
Wre denn folgendes praktikabel:
a) Export wie gehabt
b) Upload der CSV-Datei per FTP
c) Link aufrufen, der einen Import mit der hochgeladenen Datei startet
zu b) Manche FTP-Programme knnen zeitgesteuert eine Verbindung aufbauen und Dateien hochladen. Mein Hardware-Hndler aktualisiert seinen Shop genau so.
zu c) Den Teil gibt es freilich noch nicht. Die PHP-Datei mte halt statt einer is_uploaded()-Datei mit einer bestimmten arbeiten; Dateiname/-pfad wre also fest vorgegeben.
Also etwa:
Zeile 3 von admin/importitem*:
if (file_exists("./import/$datafile") && $datafile!="") {
Aufruf und Start des Imports mit einem Browser wre dann:
http://<phpay...>/backup.php?mode=Import&datafile=<dateiname.csv>
(In die spitzen Klammern sind natrlich eigene Werte einzusetzen.)
Jetzt mu nur noch die CSV automatisch generiert werden - aber das ist nicht mehr wirklich mein Problem ;-) Mit einem Cron-Job oder dem Taskplaner sollte sich das aber machen lassen.
Gru,
Andreas.
Hi, das mit der festenIP und nem eigenen Server wre natrlich der Idealfall. Sohaben wir esja auch im Einsatz. Ist allerdings auch ein wenig teurer als eine normale Flatrate.Also das mit dem Zeitgesteuerten FTP Transfer ist kein Problem. Die bertragung so zu gestalten wre auch einfach. Das einzige Problem istnun nur noch, da auch alle WWS einen Export der Daten anbieten ;-) Naja das ist eher Grundvorraussetzung fr das ganze berhaupt. Ich bastele mal so ein Proggi zusammen undstelle es hier zur verfgung. Dann knnt ihr das ganze mal probieren.
Gru
Jarno