Hello All,

We are trying to figure out exactly how, when and where EDAGET and EDAPUT are used and exactly the syntax.

From what we have been able to find out so far is that they are for "internal use" and only reside on the server. Does this mean that it varies by installation and it may not be available to everyone?

IBIers, is there specific documentation on these? And, are they commands or fexes?

And what release of WebFOCUS did they initially become available?

Thanks in Advance,
Vivian

This message has been edited. Last edited by: Vivian,

They seem to be commands, same as FILEDEF or DEFINE, executed on the webfocus agent.

EDAPUT (which reads lines of code from the input stream and stores them as temp or permanent files) is used by MR to load resolved fex code onto the WFRS agent.

Thanks Jack, but that does not give the whole story.

Syntax, parameters, etc...

and it is interesting that in the few examples that we saw all start with:

ex edaget.... leading us to think of it as a fex and not a command...but I suppose you can execute a command that way.

I am hoping that IBIers will chime in and give the specifics for each command.

Vivian

quote:

I am hoping that IBIers will chime in and give the specifics for each command

There may be a price...

Francis, I am not sure what you mean by "there may be a price?"

I would hope that IBI will want to inform the users of these 2 features. Are they a secret?

This message has been edited. Last edited by: Vivian,

I meant the price might be a beer or two.

The information must be a secret because it's impossible to find any documentation and these commands have been around a very long time.

EDAPUT as uncovered by Waz.

Hi Vivian,

See the syntax for EDAGET
This works in 716, but i am not sure in the latest versions.

APP PATH FOLDER_NAME
APP ENABLE
EX EDAGET FTM,FOLDER_NAME/FILE.ftm

This function read file from the eda server and display on the browser.

Thanks for the replies. This provides some insight into the commands. You would think (hope) that IBI would provide the definitive documentation on these 2 gems. Maybe there is some somewhere...

Vivian

quote:

ex edaget.... leading us to think of it as a fex and not a command...but I suppose you can execute a command that way.

I was thinking of

EX -LINES lineCount EDAPUT,...

where "EX -lines" is obviously a keyword phrase. (I suppose, once someone decided on the "-lines" syntax to signal special stacking for edaput, they added "EX" before it to prevent "-lines" from being taken as a dialog manager directive)

Jack, That definitely would explain it.

Thanks.

Vivian

They are just file management commands (not fexes). The PUT creates physical or memory based files, or can append to existing physical or memory based files. The GET is nothing more than a file retrieval command. Both of these commands were part of the EDA technology since version 2 (15-18 years ago). The GET was updated around version 4 (12 or so years ago) to allow binary retrievals.

I use the put for quick testing scenarios where I want to create quick content. I don't normally put it into production applications. That being said, it has come in very handy for very very specific scenarios: For example, a client had an ERP that would use a memory based XML document to manage all data changes until the data was to be committed. They wanted WF to build a PDF report of all the changes before they sent the XML object to the engine for processing. The problem is that there wasn't a physical file. We had them consume a web service for the adhoc_fex, and wrap the XML document with the EDAPUT then -INCLUDE the report at the end. That was a 10 minute solution that would have been very difficult multi-step execution without the EDAPUT.

EDAGET is just a convenient - and high performance - way to move files from the WFRS to a requester. For example, during the overnight runs, generate all the static drop down lists using ON TABLE HOLD AS xxx FORMAT XML into an application space. In the HTML file, rather than query the dimension table for the possible values, just use the EDAGET to retrieve the XML document. The drop down load will go from seconds to sub-seconds without breaking a sweat. The EDAGET also works fabulously for moving images from the WFRS to a browser in a split tier environment.

Thanks DHAGEN.

We are definitely going to update the WebFOCUS Keysheet PDF to reflect all of this information.
And, we have now come across EDACPY and EDADEL.

I am glad to see that an IBIer did chime in!

BTW --- and you are given the credit - in spite of Roger Abbott's quote.

And this all came about because Susannah raised the original question to us.

Vivian

This message has been edited. Last edited by: Vivian,

Waz documented the PUT, so here is the get:

EX EDAGET file-type,app/filename,conten-type  

file-type - same as those defined by Waz (FEX/FTM/JPG/PNG ...)
app - application space name (including foccache)
filename - only the name, no extension
content-type:
T - text (xml/ftm ...)
B - binary (png/jpg/gif ...)
H - hex (havent found a need for this one yet)


By the way, this is not official. This is just the stuff I was able to put from old doc and some custom traces I built a long time ago.

I once asked IBI for the docuemntation, and they said it was for internal use only.

So anything gained is from traces and IBI's usage in fexes

quote:

Originally posted by dhagen:
EDAGET is just a convenient - and high performance - way to move files from the WFRS to a requester. For example, during the overnight runs, generate all the static drop down lists using ON TABLE HOLD AS xxx FORMAT XML into an application space. In the HTML file, rather than query the dimension table for the possible values, just use the EDAGET to retrieve the XML document. The drop down load will go from seconds to sub-seconds without breaking a sweat. The EDAGET also works fabulously for moving images from the WFRS to a browser in a split tier environment.

Hi dhagen – Do you have a specific example of how to set this up? I would like to get faster performance for a particular control that I have that has over 9,000 records. This control is a single source tree control displaying a product hierarchy. I have created the XML as you mentioned and I have created a fex that execs the EDAGET and that works fine, but I question of how you link the fex to the HTML or do you actually insert the “EX EDAGET xml,baseapp/baseprod,t” into the HTML somewhere? If I link the fex that execs the EDAGET dynamically in the HTML Composer control property it doesn’t work for me. It locks up Developer Studio.

Thanks for the help

Reduce your XML document to 100 or so records and see if you have the same problem. 9K records is a s**t load of records to put into a web object. DS is probably not hanging, rather it is probably processing the response. If the response is working, then it will be trying to iterate through the response one element at a time. I've personally never seen any answer set > 2K process without a JS warning from the browser.

EDAGET may not be the answer here. You might want to look at a better way to manage such a large response set. There are many threads on this forum that talk about that. An example might be build a type-ahead input box and retrieve the first 20 LIKE matches.

But, to get back to your question: If you have the XML and a procedure to execute the command, then all you have to do is reference the FEX in object properties. I cannot remember what the option was in 7703, but I believe it was a radio button that states "Stored Procedure".

One more thing, the XML and T in your example should be in CAPS.

Thanks dhagen,

I got it working in the test example with the 9,000 plus records and it does bring up the page pretty fast.

The Tree Control is a special control, it doesn't load all the records at once, only at the time of expansion.

I reduced the record count in the fex and changed the case as you mentioned and that worked, then I increased the record count and that work.

Thanks for the help.