PayPal Soap Anbindung

[makulik]

Zitat von makulik:

Zitat von TiGü:

Für einen "sauberen" Workaround (ohne die gefixte Unit in das .dpr direkt einzubinden) dachte ich eher daran den Original Code zu klonen, und den gefixten Converter explizit an das entsprechende Interface zu übergeben.

Leider erweist sich diese Hoffnung als Trugschluss

Die Superklasse TRIO von THTTPRIO hat zwar die definierte Eigenschaft Converter vom (Interface) Typ IOPConverter, THTTPRIO will aber dennoch den Typ Soap.TOPToSoapDomConvert.

Was ist denn das für ein #&$**!!@ Design bitteschön???

Also kein "sauberer" Workaround möglich, es bleibt bei dem Patch (den ich jezt auch noch 2x pflegen muss, für Seattle und Tokyo, da andere Änderungen an Soap.OPToSoapDomConvert.pas vorgenommen wurden).
So ein Saftladen!!

P.S.:
Für jeden den's interessiert, hier ist das Ticket bei Embarcadero: RAD StudioRSP-20730

[TiGü]

Zitat von makulik:

Zitat von makulik:

Zitat von TiGü:

Für einen "sauberen" Workaround (ohne die gefixte Unit in das .dpr direkt einzubinden) dachte ich eher daran den Original Code zu klonen, und den gefixten Converter explizit an das entsprechende Interface zu übergeben.

Leider erweist sich diese Hoffnung als Trugschluss

Die Superklasse TRIO von THTTPRIO hat zwar die definierte Eigenschaft Converter vom (Interface) Typ IOPConverter, THTTPRIO will aber dennoch den Typ Soap.TOPToSoapDomConvert.

Was ist denn das für ein #&$**!!@ Design bitteschön???

Also kein "sauberer" Workaround möglich, es bleibt bei dem Patch (den ich jezt auch noch 2x pflegen muss, für Seattle und Tokyo, da andere Änderungen an Soap.OPToSoapDomConvert.pas vorgenommen wurden).
So ein Saftladen!!

P.S.:
Für jeden den's interessiert, hier ist das Ticket bei Embarcadero: RAD StudioRSP-20730

Du kannst es - zumindest für Tokyo - wie folgt lösen.
Der entscheidende Punkt ist das Freigeben der betreffenden Klasse in der überschriebenen ConvertSoapToNativeData-Methode.

Delphi-Quellcode:

unit Paypal.View;

interface

uses
  System.SysUtils, System.Variants, System.Classes,
  Vcl.Controls, Vcl.Forms, Vcl.StdCtrls,
  Winapi.ActiveX,
  PayPalSvc,
  Soap.SOAPHTTPClient,
  Soap.InvokeRegistry,
  System.TypInfo,
  Soap.Rio,
  Soap.OPToSOAPDomConv,
  Xml.XMLIntf,
  Soap.SOAPConst,
  Soap.TypeTrans;

type
  TfrmPayPal = class(TForm)
    Button1: TButton;

    procedure Button1Click(Sender: TObject);
  private
  public
  end;

var
  frmPayPal: TfrmPayPal;

implementation

{$R *.dfm}


type
  TMyConverter = class(Soap.OPToSOAPDomConv.TOPToSoapDomConvert)
  public
    procedure ConvertSoapToNativeData(DataP: Pointer; TypeInfo: PTypeInfo;
      RootNode, Node: IXMLNode; Translate: Boolean); override;
  end;

type
  PTObject = ^TObject;

procedure TMyConverter.ConvertSoapToNativeData(DataP: Pointer; TypeInfo: PTypeInfo;
  RootNode, Node: IXMLNode; Translate: Boolean);
var
  TypeUri, TypeName: InvString;
  IsNull: Boolean;
  Obj, DataObj: TObject;
  P: Pointer;
  ID: InvString;
begin
  Node := GetDataNode(RootNode, Node, ID);
  IsNull := NodeIsNull(Node);
  if TypeInfo.Kind = tkVariant then
  begin
    if IsNull then
    begin
      Variant(PVarData(DataP)^) := NULL;
    end
    else
      ConvertSoapToVariant(Node, DataP);
  end
  else if TypeInfo.Kind = tkDynArray then
  begin
    P := DataP;
    P := ConvertSoapToNativeArray(P, TypeInfo, RootNode, Node);
    Pointer(DataP^) := P
  end
  else if TypeInfo.Kind = tkClass then
  begin
    Obj := ConvertSOAPToObject(RootNode, Node, GetTypeData(TypeInfo).ClassType, TypeUri, TypeName, DataP);
    DataObj := PTObject(DataP)^;
    if Assigned(Obj) and Assigned(DataObj) and (Obj.ClassType <> DataObj.ClassType) then
    begin
      DataObj.Free; // <--- hier geben wir das Objekt frei, wenn die Class Types verschieden sind!
    end;

    PTObject(DataP)^ := Obj
  end
  else
  begin
    if Translate then
    begin
      if not TypeTranslator.CastSoapToNative(TypeInfo, GetNodeAsText(Node), DataP, IsNull) then
        raise ESOAPDomConvertError.CreateFmt(STypeMismatchInParam, [Node.nodeName]);
    end;
  end;
end;

procedure TfrmPayPal.Button1Click(Sender: TObject);
var
  Rio: THTTPRIO;
  PaypalInterface: PayPalAPIInterface;
  Sec: RequesterCredentials;
  Request: RefundTransactionReq;
  Response: RefundTransactionResponse;
begin
  CoInitializeEx(nil, 0);
  try
    Rio := THTTPRIO.Create(nil);
    Rio.Converter := TMyConverter.Create(Rio);
    PaypalInterface := GetPayPalAPIInterface(False, 'https://api-3t.sandbox.paypal.com/2.0/', Rio);

    Sec := RequesterCredentials.Create;
    Sec.Credentials := UserIdPasswordType.Create;
    Sec.Credentials.Username := 'hello world';
    Sec.Credentials.Password := 'hello world';
    Sec.Credentials.Signature := 'hello world';

    Rio.SOAPHeaders.Send(Sec);
    Rio.SOAPHeaders.SetOwnsSentHeaders(True);

    Request := RefundTransactionReq.Create;
    try
      Request.RefundTransactionRequest := RefundTransactionRequest.Create;

      Response := PaypalInterface.RefundTransaction(Request);
      if Assigned(Response) then
      begin
        try
          {
            Hier machen wir was Kluges mit dem Response-Objekt
          }
        finally
          Response.Free;
        end;
      end;
    finally
      Request.Free;
    end;
  finally
    PaypalInterface := nil; // nur um zu verdeutlichen, dass hier Schluss ist!
    CoUnInitialize;
  end;
end;

end.

[makulik]

Zitat von TiGü:

Du kannst es - zumindest für Tokyo - wie folgt lösen.
Der entscheidende Punkt ist das Freigeben der betreffenden Klasse in der überschriebenen ConvertSoapToNativeData-Methode.

Delphi-Quellcode:

procedure ConvertSoapToNativeData(DataP: Pointer; TypeInfo: PTypeInfo;
      RootNode, Node: IXMLNode; Translate: Boolean); override;
                                                  // ^^^^^^^^

D.h. in Tokyo sind diese Funktionen von TOPToSoapDomConvert jetzt virtuell und überladbar?

Ich hatte nicht so genau darauf geachtet, und wollte nur unseren CI Server so schnell wie möglich wieder auf green state bringen (für unseren Tokyo Branch).
Also habe ich nur den Patch für die aktuelle Version der Unit in Tokyo angepasst (5 min).

Nichtsdestotrotz finde ich das Mem-Leak im Original Code schlicht inakzeptabel, und in der Unit sind weitere fehlerhafte Stellen dieser Art zu finden.
Ich kann nur annehmen, dass das nur mit der ARC Compiler Version getestet wurde (auto ref-counting für TObject Sub-Klassen), in der wohlwollenden Annahme, das die Embarcadero Devs wirklich Unit Tests für das "Zeuch" geschrieben haben.

Ich werde Deinen Vorschlag für einen Workaround ausprobieren (vielen Dank für den Beispielcode!!). Wenn Embarcadero keinen Fix bis Okt. 2018 (unser Termin für die Umstellung des Production Codes von Seattle auf Tokyo) liefert, ist das wahrscheinlich die bessere Lösung, als die originale RTL Unit zu patchen.

Es ist schon traurig, dass man überhaupt einen Workaround implementieren muss, für eine Toolchain + Framework in dieser Preisklasse .

[jaenicke]

Zitat von makulik:

Wenn Embarcadero keinen Fix bis Okt. 2018 (unser Termin für die Umstellung des Production Codes von Seattle auf Tokyo) liefert

Ist denn auch ein direkter Supportfall bei Embarcadero offen oder nur dieses öffentliche Ticket? Eine möglichst schnelle Lösung bekommst du eher, wenn du dafür einen Supportfall aufmachst. (Drei pro Jahr sind ja in der Subscription enthalten.)

[makulik]

Zitat von jaenicke:

Ist denn auch ein direkter Supportfall bei Embarcadero offen oder nur dieses öffentliche Ticket? Eine möglichst schnelle Lösung bekommst du eher, wenn du dafür einen Supportfall aufmachst. (Drei pro Jahr sind ja in der Subscription enthalten.)

Danke für den Tip, aber die Supportfälle heben wir uns vielleicht dann doch für wichtigere (unlösbare) Probleme auf, denke ich.

Ich hab' einfach einem ihrer Chefingenieure und Evangelisten (Jim Mc Keeth) auf Twitter ein bissl in den Arsch getreten:

https://twitter.com/GntherMakulik/st...98391128297473

[TiGü]

Zitat von makulik:

Zitat von TiGü:

Du kannst es - zumindest für Tokyo - wie folgt lösen.
Der entscheidende Punkt ist das Freigeben der betreffenden Klasse in der überschriebenen ConvertSoapToNativeData-Methode.

Delphi-Quellcode:

procedure ConvertSoapToNativeData(DataP: Pointer; TypeInfo: PTypeInfo;
      RootNode, Node: IXMLNode; Translate: Boolean); override;
                                                  // ^^^^^^^^

D.h. in Tokyo sind diese Funktionen von TOPToSoapDomConvert jetzt virtuell und überladbar?

Sowohl in Berlin als auch für Tokyo ist die public-Methode ConvertSoapToNativeData als dynmamic gekennzeichnet und daher überschreibbar.
Der Fix würde also für beide Versionen funktionieren.

Zitat von makulik:

Ich werde Deinen Vorschlag für einen Workaround ausprobieren (vielen Dank für den Beispielcode!!).

Gern geschehen!

Zitat von makulik:

Es ist schon traurig, dass man überhaupt einen Workaround implementieren muss, für eine Toolchain + Framework in dieser Preisklasse .

Beschäftige dich dann mal lieber nicht mit dem internen REST-Framework.

Ich musste in Delphi Berlin darüber eine Datei schicken, was ums verrecken nicht funktionieren wollte.
Ein hinterherdebuggen zeigte, dass die gesamte Funktionalität dafür noch nicht da war bzw. auskommentiert.
Erst der Umstieg auf Tokyo und wieder eine Überschreibung einer wichtigen Methode brachte die Lösung.

Leider hat Emba die Unart, viele wichtige Klassendefinitionen nur im implementation-Teil zu schieben, was einige Fixes sehr erschwert.

[makulik]

Zitat von TiGü:

Leider hat Emba die Unart, viele wichtige Klassendefinitionen nur im implementation-Teil zu schieben, was einige Fixes sehr erschwert.

Ich pflege diese "Unart" auch, aber dann habe ich eine richtige interface Definition für die Implementierung.