SOAP-Client using InMemory - How to store physically on the serverside?

[Wolfgang Orth]

Hello Bruce and all others,

on the SOAP-Client side I do not want to store any physical data. Therefore I make the SOAP-Server to read several physical tables into InMemory-table, which then get requested by the client.

The client then reads some more data from a local CSV and finally merges the requested InMemory with those CSV-data into a new InMemory-table, which then gets sent back to the Server.

Back at the server, I want this new InMemory-table to become physical.

That means on the serverside, I have to stuff the received InMemory-table into another InMemory-tabkle on the serverside, then manually copy this one into a physical table?

The server cannot somehow receive IMDD, then automatically store to a physical file?

That no problem at all, I just need to clarify the obvious. <g>

thx in advance,
Wolfgang

[kevin plummer]

You could stuff the data into Xfiles, send that back to the server and upload that to the Physical files - it's very fast!

[Wolfgang Orth]

Yes, Kevin, everything is handled by xFiles.

But to me it seems, that the files on both sides have to be identical. Not just in the structure, but also with the names.

Actually I hope I missed something. <g>

[Bruce]

Hi Wolfgang,

Sounds to me like the table should just be set as say Topspeed on the server side, and Memory on the client side. I don't see any value in having it on the server side as a Memory table.

cheers
Bruce

[Wolfgang Orth]

Hello Bruce,

> Sounds to me like the table should just be set as say Topspeed on the server side,
> and Memory on the client side.

thats the way it is defined right now - which seems to be the problem...

> I don't see any value in having it on the server side as a Memory table.

I agree on that, but because both APPs share the same DCT, I had to declare two different tables. They are identical, except of the names, Inventory and MInventory, and the drivers, of course.

When the Client returns data to the server, the xml contains <MINVETORY:SYSID>, while the server expects <INVENTORY:SYSID>.

The queue q.MInventory holds all received records, at the end of AutoService:MInventory they exist in MInventory.
From here I would then copy to the Invertory.TPS. At least that is my desparate solution....

If the table on the clienside would have the same name, INVETORY, then the client would store data locally. Whicf is what I wanted to avoid. And changing the driver at runtime, so that I have just one declaration in the DCT, but separate tables on both sides, is not possible, isn't it?

thanks so far,
Wolfgang

 

[Bruce]

>> When the Client returns data to the server, the xml contains <MINVETORY:SYSID>, while the server expects <INVENTORY:SYSID>.

I can think of a few possible solutions to this - the most obviously doing a StringTheory.Replace on the incoming xml before it gets processed. Or better yet a stringTheory.replace on the outgoing xml on the client side before it is sent.

cheers
Bruce

[Wolfgang Orth]

>> When the Client returns data to the server, the xml contains <MINVETORY:SYSID>, while the server expects <INVENTORY:SYSID>.

> I can think of a few possible solutions to this -

I agree, there are many ways to skina cat.

> the most obviously doing a StringTheory.Replace on the incoming xml before it gets processed.

Sound like a good way in general.

But I disagree onthe following:

> Or better yet a stringTheory.replace on the outgoing xml on the client side before it is sent.

Because the WSDL-page will still tell it sends the MINVENTORY, but the the server will actually receive INVENTORY. Which is okay, if I am the only one, who sends data to the server. But as soon as software-clients from other vendors come into play, this solution breaks everything.


Another note in general: Bulk inserts by sending a TABLE or a VIEW (in this case I just guess, as I know too little about Views), anyway, processing bulk inserts will most necessarily end in some specail data-massage, at least, when the table already exist at the serverside. Lets assume a truckage company. The client has requested a particular route list of a truck, with all the planned stops along the way.
On the clientside, the route is store in an IMDD. Now the dispatcher adds a stop as also removes another. When this dataset is sent back to the server, being a table on the clientside, needs to be integrated into the existing table of all stops (child of a somewhat Job or Mission or Order parentfile).

In this case, my first attempt to tackle would be to set a delete-flag in the Route-table for all records, where Order-Nr. = x. This has to be set before the AutoServer:Insert takes place.

Going to ponder about that design while doing the laundry here now..... <g>

Thanks for reading my thoughts. Any further input is appreciated.

Wolfgang