Missing "lMessage.SetAttributes(lTransportChannel,..." since cg4 patch

Remoting SDK
1

Hi

the patch provided for SOAP Header Parameters Incorrectly Placed in Message Body since SDK V10.0.0.1595 and .1613 does break now another area in the code of another project (REST interfaces).

the line defining addition Http Infos for the methods

lMessage.SetAttributes(lTransportChannel, ['HttpApiMethod', 'HttpApiOperationId', 'HttpApiPath', 'HttpApiResult', 'HttpApiTags'], ['GET', 'GetApiVersion', 'GetApiVersion', '200', 'MilxWeb']);

disappeared after applying the patch an regenerating the Interfaces.
Digging further it looks as the new cg4 path does just skip the

<CustomAttributes>
<HttpApiPath Value="GetApiVersion" />
<HttpApiMethod Value="GET" />
...

section? Really a blocking issue now on our side.

regards

2

Hi,

HttpApi* attributes are internal attributes used in TROHttpApiDispatcher so they aren’t generated anymore.

why it is a blocking issue for you?

Note: you can get HttpAPI methods via http://localhost:8099/api path

3

Hi,

Our current development workflow that successfully created a running environment must remain functional after any updates. The “RODL first” approach needs to continue working as expected.

Best regards

4

Hello Evgeny

for the RO channels, the removal of the attributes is a valid assumption. But remember the background of the REST Server extension of RemObjects. At that time, RemObjects decided to support only the server side, but not the Client Side in Delphi.

This has brocken our approach to have a dUnitx for each Service, that tests through the API with all the supported Channels. We therefore where forced to implemented an own Channel and Message

unit ROxRestChannel; (using internally the Delphi TRESTClient component)
unit ROxRestMessage; (extracting the message attributes via TROxRestMessage.ApplyAttributes2_Transport(ATransport: IROTransport);

That approach works since 10 year and is now completely broken.

If you want to drop the HTTP Custom area in the /intf area, I do not see any easy workaround beside a new parameter for TROCodegen4 (e.g. DelphiAddCustomAttributes)

I hope you understand now my problem.

regards Günther

5

Hi,

Message.SetAttributes is needed for proper initialization of soap message only.

HttpAPI* attributes aren’t related to soap message and are required for generating HttpAPI meta data only, i.e. http://localhost:8099/api.
as a result, usage of HttpAPI* attributes in Message.SetAttributes is useless because client (_Intf) and server (_Invk) don’t use it at all.

you can use HttpAPI metadata (http://localhost:8099/api) in your ROxRestMessage.

6

Hi Evgeny

I do not see your point completely. How should my workflow now look like. I produce all files needed to implement a server and the delphi clients (REST, SOAP, Binary) in a set of calls to TROCodegen4. Now you want the workflow to change completely? Build a server first, starting the API … and still it will not work to derive from there a common dUnitx Delphi Interface.

Fact is, there was implemented a significant change that breaks my environment completely.

11

Hi,

codegen will not cut HttpAPI* attributes at processing RODL.

Note: it will work for RODL-based servers because CodeFirst ones don’t generate HttpApi* attributes at all.

12

Hello Evgeny

I patched now the xxxService_Intf by running first the CodeGen4 and then apply the necessary lMessage.SetAttributes in a post process.

The necessary information I get from TRODLLibrary created from the RODL.

Regards