Ich arbeite derzeit mit dem Dynamics CRM 4.0 Webservice. Das erste, was ich getan habe, war die Generierung der richtigen Klassen mit wsimport für Java/JAX-WS basierend auf der WSDL des Webservice. Beim Erzeugen der Klassen habe ich einige Fehler bekommen:
Zeile 979 sagt uns:
%Vor%Und Zeile 12274 gibt uns:
%Vor%Beide Teile befinden sich im selben Namensraum. Beide werden als RetrieveResponse.class generiert und kollidieren. Ich habe eine Lösung für dieses Problem gefunden, das die JAX-B-Bindungs-XML-Datei ist:
%Vor%Das funktioniert (nicht sicher, ob das der richtige Ansatz ist ..?) ..
Danach habe ich einige erfolgreiche Aufrufe an den Webservice geschafft, was großartig ist!
Jetzt kommt das Problem: Einige Geschäftsentitäten in dynamics crm verwenden die Klasse Auswahlliste . Dieser Entitätstyp kann mit dem Metadatendienst abgefragt werden: Ссылка
Das nächste, was ich getan habe, war wiederum, die Klassen für den Metadatendienst basierend auf der WSDL zu generieren. Das Ergebnis der generierten Klassen ist nicht so wie wir es sind. Beispielsweise wird eine Klasse "com.microsoft.schemas.crm._2007.webservices.ExecuteResponse" generiert. Diese Klasse existiert aber auch im exakt gleichen Paket der von CrmService generierten Klassen. Unterschiede zwischen den 2 sind:
Metadataservice ExecuteReponse:
%Vor%CrmService ExecuteReponse:
%Vor%Nun ist diese Klasse nur ein Beispiel (ein weiteres Beispiel ist CrmAuthenticationToken ), das ein fast genaues Duplikat einer anderen Klasse ist. Um die gleichen Klassen verwenden zu können, habe ich den CrmService-Klassen ein Paket-Suffix hinzugefügt (angezeigt als Präfix .). Wenn ich jetzt versuche, den CrmService aufzurufen, bekomme ich folgende Ausnahme:
%Vor%Ich persönlich finde es merkwürdig, dass sie verschiedene Klassen mit dem gleichen Namen in die gleiche Paketstruktur einfügen. Dies bedeutet, dass Sie niemals die 2 Webdienste gleichzeitig nutzen können.
Ist das ein Microsoft, ein WSimport Bug oder nur ein dummer Fehler an meinem Ende? Hoffe jemand kann mir bei diesem Problem helfen!
Danke für Ihre Zeit!
Dies ist Microsoft Inkonsistenz kombiniert mit wsimport etwas schwierig zu bedienen.
Die PickList- und CRMAuthenticationToken-Sounds klingen wie benutzerdefinierte Datentypen, von denen Sie erwarten, dass sie von Dienst zu Dienst wiederverwendet werden. Sie würden auch erwarten, dass bestimmte CRM-spezifische Entitäten (z. B. Customer oder Business oder Address) vom Service zum Service wiederverwendet werden.
Es ist schlechte Manieren auf der Microsoft-Seite der Dinge, dass sie diese für verschiedene Dienste unterschiedlich definieren. Dies macht es schwierig, die Antwort eines Dienstes zu übernehmen und an einen anderen Dienst zu senden.
Hätten die Dienste ein oder mehrere allgemeine Schemas geteilt, könnten Sie diese zuerst mit xjc kompiliert haben. Dann hätten Sie wsimport eine so genannte Episodendatei zur Verfügung stellen können, um diese zu veranlassen, diese Klassen zu verwenden, anstatt neue zu generieren. Siehe Metro Guide . Dies ist ein ziemliches Rätsel, ich kann Ihnen aus Erfahrung sagen, dass ich in den Bug JAXB-829 geriet, xjc vergisst, in der Episodendatei vorhandene Attribute zu erzeugen.
Was ich tun würde, ich würde jedes wsdl zu seinem eigenen Paket kompilieren und die generierten Klassen als einfache unintelligente Datenübertragungsobjekte behandeln. Wenn ich ein Objekt, das ich gerade von einem Dienst erhalten hatte, an einen zweiten Dienst senden wollte, würde ich zwischen beiden umwandeln. Wenn dies zu sehr unhandlichem Code führt oder wenn Sie bestimmten Entitäten Logik hinzufügen möchten, sollten Sie eigene Modellklassen für die Entitäten schreiben, die Sie freigeben möchten, und Konverter in die DTO-Objekte in den Webdiensten schreiben Pakete, mit denen Sie sie verwenden möchten.
Tags und Links jax-ws jaxb wsimport dynamics-crm dynamics-crm-4