Web services Entwicklung - brauche Rat oder Erfahrungswerte

Was ist denn der Event für den Push Service auf HP A?
Drückt jemand auf ein Knöpfchen oder passiert es zu einer bestimmten Zeit oder löst die Veränderung eines Datensatzes den Push aus?

Dgl. Verarbeitung bei HP B?

Alternativ zum Webservice gibts ja auch noch die Möglichkeit, auf HP A eine View mit CSV oder XML-Daten zur Verfügung zu stellen, die auf HP B via automatisiertem Feed-Import entgegen genommen wird.

An die Alternative habe ich noch gar nicht gedacht! Aber die Daten stehen nicht frei zur Verfügung.

D.h. das muss mit einem Knöpfchen gelöst werden zum senden der Daten.

Moin.
Nur ganz kurz in aller Schnelle: hast Du Dir mal [do:services Services] und [do:deploy Deploy] angeschaut? Eventuell wird Dein Vorhaben damit schonmal deutlich vereinfacht.

Ich wollte eigentlich irgendwie eine pro-conta liste für soap, rest etc. herausfiltern hier.

Wie du es beschreibst, bietet sich eine Batchverarbeitung mit Export am einen und Import am anderen Ende an.

An Services würde ich nur denken, wenn dies schnell und zeitnah passieren soll.

Beispielsweise sollte eine Warenwirtschaft, die mehrere Kanäle bedient, per Service angebunden sein, um auf allen Kanälen immer aktuell sein zu können.

Auch wenn ein User eine Aktion auslöst, kann es wünschenswert sein, damit dieser zeitnah das Ergebnis sieht.

Geht es um die Auswahl von Artikeln, die auf einer anderen Plattform irgendwann (nicht innerhalb von Sekunden oder Minuten) erscheinen sollen, bietet sich die Markierung an, die dafür sorgt, dass zu einem späteren Zeitpunkt, vielleicht über Nacht, eine Exportdatei erzeugt wird, die dann, ein bisschen Später, vom anderen Portal eingelesn wird.

Wenn Du nicht die einfache Export / Import-Lösung möchtest, sondern HP A als Webservice-Server einrichtest, dann wäre vermutlich als Protokoll JSON die einfachste Lösung.
Einen Mietwagen-Preisvergleich haben wir als JSON Client eingerichtet. Die Daten vom Webservice kommen allerdings nicht von einer Drupal-Webseite, deshalb kann ich dazu nichts sagen, außer daß man dazu die bereits genannten Module verwendet.
Für den JSON Client haben wir das Modul jsonrpc_client im Einsatz.

Jedenfalls sollte man sich über den Daten-Workflow genau im Klaren sein, bevor man über Details nachdenkt, wie ob soap oder rest...

ich habe nach open immo eine Immobilienwebseite entwickelt. Könnt Ihr im showroom sehen, mia casa immobilien. Der Fokus lag dabei darauf, möglichst einfach eintragen zu können. Könnt Ihr jetzt ncht sehen. Das front Design spielt hierbei keine gesonderte Rolle, da der Kunde ja bestimmt hat was er will und was nicht.

Jetzt habe ich hier einen fetten code liegen, mit 6 eigens entwickelten Entities, und trage mich mit dem Gedanken zum einen eine Distribution auszugeben, so dass auch Drupaler, die nicht selbst entwickeln können, Seiten anbieten können, zum anderen möchte ich eine eigene Marketingplattform entwickeln.

Der Sinn der Plattform:

Es gibt eine Masse an Maklern am Markt, die Probleme haben ihre Objekte richtig auf den verschiedenen Portalen einzupflegen und zu organisieren. Vor allem Einzelkämpfer und kleinere Teams.

Daher möchte ich einen Service (als Dienstleistung gemeint) entwickeln, der ihnen die Pflege auf den verschiedenen Plattformen abnimmt oder zumindest erleichtert.

Mein Fokus liegt dabei darauf, dass die Makler möglichst einfach agieren können. D.h. es sollen ihnen Entscheidungen abgenommen werden können. So soll für den Makler Zeit- und Geldersparnis entstehen.
Der Server Service soll daher passiv sein, der Client Service entweder per cron oder manuell anzustossen sein.

Der einfache User soll mit einer vereinfachten Oberfläche Objekte erfassen können, die später (evtl. über Nacht) in das eigentliche Portal eingespielt werden sollen.

Das schreit doch nach Batchverarbeitung ;-)

Alle Objekte auf einen Stapel, und per Import eingelesen.

Nur, warum ist die eigentliche Oberfläche zu kompliziert?

Oder soll eine Redaktionsebene zwischengeschaltet werden?

Wenn das der Fall ist, kann man das "Veröffentlicht" - Flag auf falsch stehen lassen, bis ein Redakteur die Anzeige frei gibt.

Also so richtig klar ist (zumindest mir) der Datenfluß noch nicht.

Off-Topic: Die Immobilien-Webseite gefällt mir gut, weil sie so schön übersichtlich ist. Ich hasse diese überladenen Immo-Seiten...

Ansonsten kann ich nur empfehlen (weil wir gerade an einer ähnlichen Konzeptionierung für eine Handelsplattform / B2B-Marktplatz sind):
Datenfluss, Akteure, Rollen, Berechtigungen, Entities, Prozesse erst mal mit einem Tool als Diagramm aufmalen (z.B. mit dem OpneSoruce-Tool Dia).
Dabei erst mal ganz weit weg bleiben von jeder Überlegung zur technischen Umsetzung.

Wenn das klar ist und auch mit Akteuren, die das bedienen müssen auf Akzeptanz geprüft ist, dann würde ich in die technischen Details gehen.
Frei nach dem Motto: Gehen tut alles, aber ist es auch sinnvoll?

Das Komplizierte liegt an der Eingabe und Organisation der Daten. Es gibt tools wie openestate.org als Desktopapp, die sind so schwierig zu bedienen für so manchen Immomakler, dass er das aufgegeben hat.
Je mehr Möglichkeiten Daten einzugeben existieren, um so mehr inhaltliche Fehler werden begangen.

Das war der hook es etwas anders zu konzipieren als alle anderen. Die Reaktionen der Bearbeiter sind positiv.

Ausserdem habe ich ein Minimal-CRM mit eingegeben. Füllt jemand das Kontaktformular aus, so werden seine Daten an das entsprechende Objekt gebunden. Weiters werden die Verkäuferdaten pro Objekt aufgenommen.

Dies alles ist bisher nur dazu da, schnell und einfach die nötigsten Handlungen zu vollziehen, der Objektpflege der Hp und der Kundenpflege (Verkäufer, Käufer) pro Objekt sowie drucken des Exposes.

Theroretisch könnte ich noch actions zur entity hinzufügen, sowie eine Kalenderfunktione etc, dann hätte ich ein rudimentäres CRM drin, ich habe aber festgestellt dass gerade im Kleckersegment die wenigsten Makler gerne schreiben ("Habe ich im Kopf"). Demnach ist das zu viel.

Die Datenpflege, nachdem das Objekt angelegt ist, ist Herausforderung Nummer 2, und das ist das hier gemeinte Problem:

Es gibt Makler, die haben keinen Überblick über ihre Objekte und auf welchen Portalen diese geschaltet sind, das kann teuer werden. Weiterhin bedienen sie auch häufig falsch und haben keinen Leistungsnachweis. Da wird in irgendein Portal mal rein copy pasted, dann aber vergessen es rauszuholen, falls es von einem selbst oder von anderen Maklern verkauft wird. Manchmal schlicht und einfach weil sie nicht wissen dass es verkauft wurde.

Daher ist es wichtig, ein Redaktionssystem zu entwerfen. Das soll per senden button ein batch ausführen können, und, Diskussion hier sei Dank, per cron auch importieren können.

Vielen Dank Ronald für diese Anregung, hat mich schon weiter gebracht.

Ja, ich nehme zur Konzeption auch Dia. Und Akzeptanz ist dahingehend da, dass mein Auftraggeber mich schon die ganze Zeit nervt wie weit ich bin.
Der stellt sich das immer ein bisschen einfach vor, 3 Klicks, fertig!

Du kannst natürlich gewisse Daten, die mehr oder weniger immer gleich sind, vorbelegen.

Wenn die Daten aber benötigt werden, müssen sie irgendwo herkommen.

Dafür brauchst du aber nicht zwangsläufig ein externes Tool. Drupal bietet dir alles, was du brauchst.

Warum Daten an einer Stelle erfassen, um sie an anderer Stelle neu einzulesen, wenn du die Daten nur miteinander zu verknüpfen brauchst?

Deshalb ist es, egal mit welchen Mitteln du entwickelst, wichtig, dass du vorher weißt, welche Daten zu erfassen sind, welche Daten optional sind, und in welchen Strukturen sie weiter verarbeitet werden sollen.

Ehe du mit irgendwelchen Methoden eine Oberfläche bastelst, muss die Datenstruktur klar sein.

Ansosnten ist dies der beste Ansatz, um irgendwann in der Klapse zu landen ;-)

weil Auftraggeber meinen, wenn das Konzept so hübsch aussieht, ist die Entwicklung quasi abgeschlossen.

Dass anständige Entwickler erst dann mit der Arbeit beginnen, verstehen einige Endanwender nicht.

Das mit der Verknüpfung ist mir nicht klar!

Also: Imomakler lässt HP von drupaler bauen. Dann kann er sich erstmal entscheiden ob oder ob nicht er den Service in Anspruch nimmt. Wenn ja werden Daten übernommen, per Service, oder? Eine Verknüpfung wäre doch nur dann möglich, wenn das Serversystem auf die DB vom Client Zugang hätte, was unwahrscheinlich ist, da es nicht wissen kann wo die Db des Clients überhaupt liegt, Imho. Sehe ich das falsch?

zwischen Datenstruktur und individuellen Daten.

Wenn ein neuer Kunde das Produkt einsetzt, werden dort sicher keine Daten enthalten sein, außer eventuell allgemeingültiger Begriffe etc., die man mit einer Distribution mitliefern, und bei der Installation importieren kann.

Wenn das System Schnittstellen zu anderen Systemen haben soll, kann man sicher Im-/Exportschnittstellen implementieren, oder gar Services bereit stellen.

Das ist aber eine ganz andere Baustelle, weil man hierbei auf die Definitionen der anderen Systeme angewiesen ist.