Zugriff Auf Bereits Vorhandene Daten(banken)

[RHansmann]

Groooosssssartige Leistung, dieses XT-Commerce. Gef?llt mir ausgevorz?glich. Hab bereits intensive Erfahrungen mit osCommerce gesammelt und denke, dass ich dass ganz gut beurteilen kann.

Trotz alledem ich m?chte hier mal eine Diskussion anzetteln ?ber ein Thema, welches mich bei allen Shopsystemen st?rt:

Fast jedes Shopsystem, sofern es nicht als integraler Bestandteil einer anderen Software entwickelt wurde - und soweit ich das sehe, auch XT-Commerce - tut so, als ob es allein auf der Welt ist. Dies betrifft sowohl Adress- als auch Artikelverwaltung. Jedoch gibt es in allen Unternehmen - seien sie klein oder gross - bereits vorhandene Warenwirtschafts- und/oder Buchhaltungssysteme, in denen diese Daten in der Regel vorhanden sind. Es w?re eine schicke Sache, wenn - statt die Daten in der XT-Commerce Datenbank abzulegen - die relevanten Daten, sofern sie vorhanden sind, aus dem anderen System verwendet und verwaltet werden k?nnten anstatt alles doppelt zu verwalten oder spezielle Import-/Export-Funktionen f?r jedes Fremdsystem erstellen zu lassen. Dies bezieht sich auch auf Bestellungen, die meines Erachtens direkt als Auftrag in der Auftragsverwaltung gespeichert werden sollten (entweder zus?tzlich zu XT-Commerce oder stattdessen).

Hierzu bedarf es meines Erachtens eines flexiblen Zugriffsmoduls f?r Adressverwaltung, Artikelverwaltung und Bestellausl?sung, welches in der Lage ist, sich bei Bedarf an andere Datenbanken und andere Tabellen (auch mit evtl. anderen Strukturen) anzudocken, um vorhandene Daten zu nutzen und zu verwalten.

Dies ist meines Erachtens ohne riesigen Aufwand m?glich, wenn ein vern?nftiges Konzept erarbeitet ist. Ich habe hier bereits einige Erfahrung mit compilierten Programmiersprachen gesammelt, bei denen es weitaus komplizierter war, eine solche Funktion zu realisieren als bei einer Skriptsprache ? la php, welche dynamisch generiert und ausgef?hrt werden kann.

:dafuer: Falls Ihr (die Entwickler!) Euch erweichen lassen k?nntet, hier eine entsprechende Anpassung zu realisieren, w?rde ich mich bereit erkl?ren, Euch hierbei intensiv zu unterst?tzen. Entsprechender Skill ist vorhanden. Als zus?tzliches Modul (also contribution) ist dies leider nicht realisierbar, da doch Eingriffe an verschiedenen Stellen in diversen Modulen vorgenommen werden m?ssten.

Mich w?rde mal interessieren, was andere hierzu anzumerken haben.

Danke und Gruss

Reinhard

[mzanier]

XT-Commerce darauf zu biegen heir direkte export/import funktionen f?r spezielle bereiche zu geben ist nicht wirklich sinnvoll, da dies einen enormen aufwand an schnittstellenpflege mitsich bringt.

auch die angesprochene direkte verbindung von XT-Commerce mit einer wawi datenbank ist auch relativ schwer zu realisieren, da einfach zu viele produkte auf dem markt sind, ohne einhautlich genormte schnittstellen.

solange die industrie hier kein einheitliches format f?r den datenaustausch entwickelt, liegt es im bereich des unm?glichen hier ne "flexible" l?sung zu relasieren.

ich pers?nlich kann da eher in richtung schnittstellenserver verweisen.

durch ein solches system k?nnen auch DB(n) applikationssysteme vernetzt werden, sofern gewisse verkn?pfungen vorgenommen werden k?nnen.

dies sind zentrale programme mit mehreren schnitstellen wo zb automo Wawi und shopsysteme ankn?pfen, dieses programm verteilt/?ndert dann die einzelnen daten in alle relevanten datenbanken, so wird das auch in sehr komplexen systemen betrieben, somit kann auch eine gewisse datensicherheit in empfindlichen bereichen gew?hrleistet werden.

eine anbindung an einzelne wawis ist in der regel kein problem, dies wird von uns aber nicht opensource erledigt, was auch verst?ndlich ist, aber ne global g?ltige l?sung zu finden w?re nur mit enormen aufwand m?glich.

aber ich bin f?r jeden vorschlag offen.

mfg,

mario

[RHansmann]

Hallo Mario!

Also ich bin nicht ganz bei Dir, da ich es wesentlich schicker finde, wenn man Daten dort liest und speichert, wo sie bereits vorhanden sind. Schnittstellen-Server haben meistens den Nachteil, dass keine Daten weitergeschoben werden, wenn der Server und/oder das Zielsystem nicht da ist. Ausserdem ist das Ganze ganz sch?n aufwendig zu konfigurieren. Eine bessere L?sung ist da schon eine Middleware mit sauberem Messaging. Aber das kann und will wahrscheinlich auch nicht jeder bezahlen, da ganz sch?n teuer.

Ich m?chte eigentlich eine Art Standardschnittstelle aus XTC heraus, die flexibel programmierbar f?r die jeweilige Anforderung ist.

Ich stelle mir das relativ simpel vor:

1. Neues Subdirectory, sagen wir mal "Customizations" einrichten, in der ich

als Fremdprogrammierer meine Anpassungen ablegen kann

2. Bestellausl?sung:

Wenn eine Bestellung aufgegeben wird, beim Speichern der Daten pr?fen,

ob im oben angelegten Verzeichnis ein Skript mit einem bestimmten Namen

vorhanden ist und dieses einfach aufrufen. In diesem Skript kann ich dann

treiben, was ich m?chte.

3. Adressverwaltung:

Adressdaten werden generell in einem benannten Array vorgehalten.

Das Lesen und Schreiben von Adressdaten wird generell in eine separate

php-Datei ausgelagert. In dieser Datei gibt es eine Hauptfunktion, in die eine

Datei analog Punkt 2 inkludiert wird. Standardm?ssig wird in der Hauptfunktion

ein Flag gesetzt, welches besagt, dass XTC verwendet werden soll.

Dieses Flag kann in der inkludierten Datei allerdings ?berschrieben werden.

Nun frage ich in der Hauptfunktion ab, ob die XTC-Datei gelesen oder

geschrieben werden soll und rufe eine weitere Funktion auf, die die Standards

von XTC ausf?hrt. Anschliessend f?hre ich die Statements der inkludierten

Datei aus und kann hier treiben was ich will. Mit dieser Art, Dateizugriffe zu

steuern, kann ich sogar das Lesen und die Updates in die Originaltabellen

unterbinden und ausschliesslich ein Fremdsystem benutzen. Alternativ habe

ich alle Varianten an Updates in Kombination zur Verf?gung.

4. Artikelverwaltung:

Hier w?rde ich ein zus?tzliches Modul erstellen, welches wiederum ?ber eine

eingebettete Datei flexible Zugriffe auf ein Fremdsystem gestattet und mir

Artikel anzeigt, die ich noch nicht im Shop habe. ?ber eine Auswahl kann ich

einen Artikel nehmen und an das Modul Kategorien-/Artikelpflege ?bergeben.

Ich denke, dass es nicht sinnvoll ist, direkt an einen Artikelstamm eines

anderen Systems zu gehen, da es shopspezifische Daten gibt, die in der

Regel in dem anderen system nicht abbildbar sind. Ausserdem kann es ja

gew?nscht sein, nicht alle Artikel im Shop aufzunehmen. Aber hier h?tte ich

eine Unterst?tzung bei der Artikel-Pflege, so dass mir im Shop nichts entgeht.

Zus?tzlich kann man nat?rlich auch eine Funktion wie unter Punkt 3 erl?utert

zur Verf?gung stellen.

Wie Du siehst, ist das Ganze gar nicht so schwer. Ich sch?tze den Programmieraufwand, um den Standard in XTC entsprechend zu modifizieren ohne die flexible L?sung aus Punkt 3 auch bei den Artikel einzubauen) auf 1 bis 2 Tage, da an so vielen Ecken ja doch nicht mit den Adressdaten gearbeitet wird.

Nat?rlich m?sste ein Entwickler jeweils eine Anpassung an ein spezielles WaWi-System vornehmen. Da aber eine Standardschnittstelle in XTC bereits vorgesehen w?re, k?nnte man trotz individueller Anpassung weiterhin an der Weiterentwicklung von XTC partizipieren. Ich finde, dass eine propiet?re Anpassung innerhalb von XTC den Anwender von der Weiterentwicklung entweder aussperrt oder permanente Anpassungen verursacht.

Was h?ltst Du von dieser Idee? Dies ist meines Erachtens keine grosse Sache. Selbstverst?ndlich kann man das Ganze auch auf alle Dateien ausweiten, aber das w?rde meines Erachtens die Grenzen ein Standardshops doch bei Weitem sprengen.

Ausserdem h?rt sich das alles jetzt vielleicht komplizierter an, als es ist.

Gruss

Reinhard

[mzanier]

jo alles sch?n und gut, jedoch muss man bedenken das man systeme implentieren muss mit denen auch ein standart user umgehen kann, deshalb sollte man hier eher in richtugn individuelle l?sungen f?r schnitstellen gehen, die auch nicht "live" arbeiten, sondern externe programme die direkt auf die shopdatenbank zugreifen, und dann einfach per drag&drop die jeweiligen zu export/importierenden felder ausw?hlbar sind, das reicht f?r die meisten user, wer automatische synchronisationssysteme haben will/braucht der ben?tig sowieso individuelle l?sungen.

siehe zb. shopexpress

und eine sog. implentierung einer standart schnitstelle in xtc hat eigentlich wenig sinn, da man hier auch einfach mit java systemen direkt auf die db zugreifen kann, ist auch ein wesentlich geringerer entwicklungsaufwand, hier spielen wirklich zuviele individuelle faktoren mit um etwas global einsetzbares zu entwickeln, es w?rde sich hier ja um ne komplette neuentwicklung einer datenschnittstelle handeln, das muss mal sehr genau unter die lupe genommen werden wo ?berhaupt die anforderungen sind, welche relevante daten ben?tigt werden, etc. handling von daten mit anderen datenbanken hier ?ber ein einfaches php script zu l?sen w?re imho zu komplex aufgrund der datsache das es sich hier im kritische daten handelt die verlustfrei ?bertragen werden m?ssen, das ist bei so einer l?sung leider nicht immer der fall, braucht nur mal der server aussteigen usw.

sowas muss ?ber ein externes programm geschehen das direkt auf die online db zugreift und die daten demensprechend handelt.

mfg,

mario

mfg,

mario