Fachrat Informatik - Forum

Hi,

habe wohl parallel schon geantwortet

zu 1.: Siehe parallelen Thread .

zu 2.: Was für Testdaten meinst du? Du kannst einfach einen Client bauen, der die beiden Methoden einmal aufruft. Welche Daten du dabei sendest ist egal.

die Rückgabewerte der Services sind von der Id-Länge abhängig und bei beiden wohl gleich

Ja, die Preisberechnung ändern wir noch bis zur nächsten Übung. Sie wird aber weiterhin abhängig von der Produkt-ID sein.

Gruß,
Kai

Wie schaffe ich es, an die beiden WSDL-Dateien zu gelangen? Wenn ich den Links folge und die Dateien speichere, sind sie nicht verwendbar...?
EDIT: Ok, hat sich erledigt, es funktioniert doch. Keine Ahnung, woran das nun vorgestern wieder lag

Hi Leute,

ich habe Tutorian Invoke gemacht, habe folgende Fehlermeldung bekommen, wenn ich "http://localhost:8080/ode/processes/SimpleInvokeService/process?input=Donald" angebe:

<soapenv:Fault>
<faultcode>soapenverver</faultcode>
<faultstring>axis2ns2:selectionFailure</faultstring>
<detail/>
</soapenv:Fault>

Wenn ich "http://localhost:8080/ode/processes/SimpleInvokeProcess/process?input=Donald" angebe,dann kommt Fehlermeldung:

DEBUG - GeronimoLog.debug(66) | Checking for Service using target endpoint address : /ode/processes/SimpleInvokeProcess/process?input=Donald
DEBUG - GeronimoLog.debug(66) | Found service in registry from name SimpleInvokeProcess/process: null

Endpunkt bei mir ist : http://localhost:8080/ode/processes/SimpleInvokeService

hat jemand auch sowas bekommen?

Nun doch eine Frage. Der Wrapper bekommt als Input einen String, was ich daraus erzeugen möchte ist ja ein Request nach dem Preis oder einem Produkt. Ist die pick-Operation so schlau, den Input in die korrekte Form umzuwandeln (d.h., eine Nachrichtenvariable des passenden Typs mit dem Inhalt des Strings zu füllen), oder läuft das anders?

Dein Wrapper bekommt als Input eine SOAP-Nachricht, die entweder die Nachricht getPriceForProductRequest oder orderProductRequest enthält. Die BPEL-Engine (ODE) kann das auseinander halten und weist den Inhalt der in onMessage angegebenen Variable zu, sofern sie eine Message-Variable eines der gerade genannten Typen ist. Also ja, die pick-Aktivität ist so schlau das selbst zu machen. Handarbeit ist also erst nötig, wenn ihr den Request für den zu wrappenden Aufruf zusammen bauen müßt.

Danke erstmal für Deine Antwort. Mh, aber ich muss ja in receiveInput schon spezifizieren, in welche Variable die empfangene SOAP-Nachricht geschrieben wird, und die ist vom Typ erstmal ein String. Das wäre ok, wenn die pick-Aktivität mir die Nachrichten dann über diesen Umweg in Behemoth-Requests wrappt. Habe ich das so richtig verstanden?

Ein Problem bliebe dann noch: Wie bekomme ich später die zwei verschiedenen Response-Messagetypen des Behemoth-Services wieder zurück in einen String umgewandelt, den ich dann in replyOutput zurückgebe?

Quoted from "DrChaotica"

Danke erstmal für Deine Antwort. Mh, aber ich muss ja in receiveInput schon spezifizieren, in welche Variable die empfangene SOAP-Nachricht geschrieben wird, und die ist vom Typ erstmal ein String. Das wäre ok, wenn die pick-Aktivität mir die Nachrichten dann über diesen Umweg in Behemoth-Requests wrappt. Habe ich das so richtig verstanden?

Nein, du brauchst, wenn du pick benutzt, kein receive mehr. Das was du sonst in receive spezifiziert hättest, packst du jetzt in onMessage. Die BPEL-Engine entscheidet dann, welche Nachricht empfangen wurde und packt sie in die entsprechende Variable und lässt den dazu gehörigen Unterprozess ablaufen.

Und nein, die SOAP-Nachricht ist vom TYP kein einfacher String, sie ist XML, die als Nutzinhalt (Body-Element) wieder XML enthält, der z.B. so aussehen könnte:

Quoted from "DrChaotica"

Ein Problem bliebe dann noch: Wie bekomme ich später die zwei verschiedenen Response-Messagetypen des Behemoth-Services wieder zurück in einen String umgewandelt, den ich dann in replyOutput zurückgebe?

Jede Unteraktivität in der Pick-Aktivität enthält ein eigenes Reply. Es wird ja auch immer nur ein Strang ausgeführt.

Gruß,
Kai

Quoted from "KaiStapel"

Nein, du brauchst, wenn du pick benutzt, kein receive mehr. Das was du sonst in receive spezifiziert hättest, packst du jetzt in onMessage.

Ah, stimmt, das hattest Du ja auch in dem anderen Thread geschrieben...hab es übersehen.

Quoted from "KaiStapel"

Und nein, die SOAP-Nachricht ist vom TYP kein einfacher String, sie ist XML, die als Nutzinhalt (Body-Element) wieder XML enthält, der z.B. so aussehen könnte:

	Source code
1 2 3 4 5 6	<getPriceForProduct> <product> <productId>SN34/342-A435</productId> <vendor>SE-WorldWide-Trading-Group</vendor> </product> </getPriceForProduct>

Ich hatte mich falsch ausgedrückt...die SOAP-Nachricht ist XML, das habe ich soweit schon verstanden. Aber als payload im Body erwartet der Proxy-Service, so wie er in der WSDL beschrieben wird, doch standardmäßig einen String? Müsste man nun dort nicht noch die payload-Datentypen für Request und Respond so abändern, dass sie beliebige XML-Nachrichten enthalten können? Oder ist ein String dafür schon ausreichend? (vermutlich schon. nur passiert leider soviel im hintergrund, worüber man noch keinen überblick hat... bloß, zusammensetzen muss man es trotzdem)

Mh, aber ich denke, das Konzept haben wir jetzt schonmal verstanden...bleiben nur noch die üblichen Details, und dann läuft der Service hoffentlich auch

Hi,

kannst Du mir bitte Deinen BPEL-Prozess schicken?

Daniel

Quoted from "alanhome"

Hi Leute,

ich habe Tutorian Invoke gemacht, habe folgende Fehlermeldung bekommen, wenn ich "http://localhost:8080/ode/processes/SimpleInvokeService/process?input=Donald" angebe:

<soapenv:Fault>
<faultcode>soapenverver</faultcode>
<faultstring>axis2ns2:selectionFailure</faultstring>
<detail/>
</soapenv:Fault>

Wenn ich "http://localhost:8080/ode/processes/SimpleInvokeProcess/process?input=Donald" angebe,dann kommt Fehlermeldung:

DEBUG - GeronimoLog.debug(66) | Checking for Service using target endpoint address : /ode/processes/SimpleInvokeProcess/process?input=Donald
DEBUG - GeronimoLog.debug(66) | Found service in registry from name SimpleInvokeProcess/process: null

Endpunkt bei mir ist : http://localhost:8080/ode/processes/SimpleInvokeService

hat jemand auch sowas bekommen?

Quoted from "alanhome"

<soapenv:Fault>
<faultcode>soapenverver</faultcode>
<faultstring>axis2ns2:selectionFailure</faultstring>
<detail/>
</soapenv:Fault>

Dieser Fehler deutet darauf hin, dass eine Variable nicht initialisiert ist. Höchst wahrscheinlich die output-Variable.

Gruß,
Kai

Quoted from "Finn MacCool"

Quoted from "DrChaotica"

Müsste man nun dort nicht noch die payload-Datentypen für Request und Respond so abändern, dass sie beliebige XML-Nachrichten enthalten können? Oder ist ein String dafür schon ausreichend? (vermutlich schon. nur passiert leider soviel im hintergrund, worüber man noch keinen überblick hat... bloß, zusammensetzen muss man es trotzdem)

ich denke, man müsste das so abändern, dass etwas vom typ Product erwartet wird

Naja, das mag hier für den Request mal zufällig funktioneren, für den Respond aber wiederum nicht, weil die Typen ungleich sind. Da sollte schon etwas allgemeineres her...

Irgendwer wollte heute noch mal in der Übung wissen wie man dem BPEL-Service als Input die Typen vom Behemoth-Service angibt.
Ich habe das so gelöst:

Alles in der artifacts.wsdl
Die Behemoth-wsdl per Import einbinden:
[codefile]
<import location="BLSupplier.wsdl" namespace="http://behemoth.service.suppliersguild.org"/>
[/codefile]

Den Namenspace in den Definitions angeben
[codefile]<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:behem="http://behemoth.service.suppliersguild.org"
...
targetNamespace="http://carl.volhard.de/Wrapper">[/codefile]

und dann in den Porttypes direkt auf die Messages in der Behemoth-wsdl bezogen
[codefile]<portType name="Wrapper">
<operation name="getPriceForProduct">
<input message="behem:getPriceForProductRequest"></input>
<output message="behem:getPriceForProductResponse"></output>
</operation>
<operation name="orderProduct">
<input message="behem:orderProductRequest"></input>
<output message="behem:orderProductResponse"></output>
</operation>

</portType>[/codefile]

Im BPEL-Editor dann nur noch für Input/Output die Datentypen der Behemoth-WSDL auswählen (wie beim Invoke, mit add Schema oder WSDL)

Im Designeditor der WSDL wird dann der Behemoth-Service auch angezeigt und die Operationen des BPEL-Prozesses erhalten auch die richtigen Eingaben (Editor nach dem ändern neu starten).
Hin und wieder hat mir Eclipse die WSDL wieder überschrieben, wenn es also Fehler gibt, mal gucken ob noch das Richtige in der WSDL steht.