Ist Sharepoint die richtige Plattform für große ERP-Anwendungen?
Ich wurde beauftragt mit der Entwicklung von einigen großen ERP-Anwendungen (einige ältere apps werden umgeschrieben und einige neue apps in Sharepoint. Als ich gekommen bin, zu beschleunigen, die in Sharepoint, sehe ich den Wert und die einfache Erstellung von team-sites, und die Beispiele, die ich im Netz gefunden habe und in Büchern sind zugeschnitten auf die intranet-Abteilung-Portalen oder das einfache line-of-business-apps für Unternehmen, die nicht über große legacy-ERP-Systeme. Ich habe angefangen zu glauben, dass, wenn man geht, um eine große Anwendung, die Schnittstellen zu verschiedenen legacy-Systemen und erstreckt sich über mehrere Abteilungen, die Gebäude, benutzerdefinierte webparts in Sharepoint ist einfach nicht der Weg zu gehen.
Ist Sharepoint eine tragfähige application framework für die Erstellung und das hosting von großen ERP-Anwendungen?
Wenn ja, kann jemand bitte zeigen Sie mir Referenzen beschreiben die Architektur eines solchen Systems?
Wenn nicht, kann jemand bitte zeigen Sie mir Referenzen, die kann ich zitieren als Argumente für nicht es zu benutzen?
- Dies ist ein weiteres Thema, das im Zusammenhang mit diesem, aber es ist die Adressierung 2013-version. Wesentliche änderungen seit der letzten version 2007. Ich denke die Antworten sollten überprüft und geändert für das neue Thema. stackoverflow.com/questions/16997286/...
Du musst angemeldet sein, um einen Kommentar abzugeben.
Als jemand, verbrachte die letzten 15 Jahre geschrieben ERP-Anwendungen würde ich sagen, Sharepoint wäre eine äußerst schlechte Wahl, auf die man bauen kann ein ERP-Produkt.
Sharepoint eignet sich gut als portal in die bestehende LOB-Anwendungen, nicht als eine Plattform zu bauen, die eine Daten-reiche Anwendung, die auf.
Ich bin momentan auf der Bereitstellung von einer ERP-system, geschrieben in Sharepoint für einen client. Ich habe dies für etwa ein Jahr jetzt, und von dem, was ich gesehen habe, Sharepoint eingeführt, wie viele Hindernisse es machte die Dinge komplizierter.
Dinge einfacher gemacht:
Dinge, die sog:
Ich würde empfehlen, das Lesen Real World SharePoint 2007: Unverzichtbare Erfahrungen Aus 16 MOSS-und WSS-MVPs, bevor Sie eine Entscheidung
Ich die Verwendung von SharePoint 2007 (MOSS) bei der Arbeit als Teil einer größeren ERP-installation. Wir stark mit dem Business Data Catalog, um eine Schnittstelle mit externen Systemen und machen Sie Ihre Daten sichtbar und durchsuchbar in unserem MOSS-portal.
In unserer Architektur, der CRUD-Operationen auf die ERP-Daten in unser ERP-business-line-Systeme. MOSS und der BDC dann ziehen Sie die Daten aus der ERP-Datenbank und zeigen Sie Sie als datagrids eingebettet in verschiedene portal-Seiten. Zum Beispiel, die HR-Website hat eine MOOS-Seite für die Sendungsverfolgung den aktuellen status der ausstehenden performance-Berichte.
Andere überzeugende Funktion von MOSS und der BDC ist die Fähigkeit, sich zu entlarven BDC datasources zu den MOOS-such-service. Zum Beispiel, wenn ein Benutzer sucht nach John Smith mit MOOS suchen, das öffentliche ERP-Rekord für John Smith ist inline mit den Suchergebnissen. Klicken Sie auf den link in den Suchergebnissen leitet den Benutzer auf die richtige Seite in unserem ERP-system, eher als, Sie in einer MOOS-Seite.
Wir nicht verwenden, MOSS ausschließlich als ERP-system, aber wir verwenden es als eine Präsentation und reporting-Schicht auf der Oberseite von unserem ERP-system.
Dem MS Dynamics AX system nutzt Sharepoint umfassend, in der Tat gibt es tool-kits, die es ermöglichen Benutzern das erstellen von web-parts und so weiter extrahieren von Daten direkt aus der Basis AX-Objekte. Hier ist ein link, der spricht ein wenig über die Sharepoint-integration AX+SP. Momentan ist es noch ein erheblicher Teil von AX, die sich nicht innerhalb von Sharepoint, sondern Ihre Richtung wird zu Sharepoint ermöglichen einen erheblichen Teil der Anwendung. Ich glaube nicht, dass das komplette ERP-system könnten Wohnsitz innerhalb der Sharepoint-Infrastruktur, sondern von einem MVC-Perspektive könnte es sicherlich werden Ihre View-Infrastruktur. Es scheint mir, dass dies der Richtung MS geht, aber ich bin nur die Hypothese auf, Ihre Pläne für die Zukunft.
Erstellen benutzerdefinierter webparts in SharePoint wäre nicht der Weg zu gehen für komplexe legacy-Systeme.
SharePoint würde noch geben Sie eine Menge von der Laufleistung, wenn Sie erstellt eine benutzerdefinierte navigation-provider für die Haupt-navigation (basierend auf einer xml-Datei zum Beispiel). Dies würde es ermöglichen, benutzerdefinierte asp.net Seiten anzeigen, "wie" Sie waren immer noch Teil von SharePoint, gibt die illusion der eine allumfassende app.
Ich denke, der einzige Grund, warum Menschen wollen eine riesige Anwendung hat mehr zu tun mit Informationen, die Architektur, das Aussehen und das Gefühl und Auffindbarkeit als jede technische Architektur Gründen.
Einer Lösung, die erstellt separate websites für die entsprechenden Anwendungen, die noch gehäutet und verbunden, die in die SharePoint-Informationsarchitektur und noch durchsuchbar aus dem Hauptfenster lösen könnte, die "Notwendigkeit" für den "Enterprise" - Teil von ERP -, während immer noch die Schaffung geeigneter Lösungen für das, was wirklich getrennte Anwendungen.
Dem mentalen Modell, das ich benutze, ist nicht so sehr die Gebäude, die apps "in" SharePoint, aber die Schaffung eines "Fensters" in SharePoint verfügbar machen die app.