I admit to not reading enough before posting this question, ...

[Toby Mills]

Well, it has been a while (and I think I heard that the last RA programmer in Florida was let go), but my guess is that you could do that via RG, but- unlike RA, RG is not free. So, thats one strike. You would have to get up to speed in generating the rules - I would download the manual to get a sense if the rules can check for userid / focexec name / number of occurrences of same.

Honestly, in the spirit of KISS, I would make it DEFER or LIBRARY only- ACE ran their entire ad-hoc environment in DEFER , and it just wasnt a problem (of course, that also was few years ago).

I checked the list of REST calls (I am doing some research for another issue) and surprise, there was no (as of 8.2.01) REST call(s) - that I saw - that would query and kill jobs/userids the way youre describing (disclaimer- using REST as a data source used to require a license; using REST as a webservice didnt used to, but again, this is all from memory).

Again, ALL stated observations about licensing are six years old; check on that. Occams Razor also works for program design. Cant wait to see other opinions- have fun.

[Warren Hinchliffe]

Have you thought about putting a limit on the service that the job is running in (set to 60 seconds), so the report will kill its self, then resubmit deferred (different service with longer or no timeout)

[Toby Mills]

I didnt know the idea that a Data Service had the ability to resubmit deferred That could work as long as I get some feedback to the end user.

I see the CPU limit

 

image.png1147231 19.9 KB

 

But - if they hit this limit and they get cancelled, what mechanism might make the job resubmit as deferred

Steve - Ill look to see if theres anything there. I think we already pay for RA, but I thought RG was part of the package (thus we always called it RARG). And yes - if youre talking about Bruce (BEC), officially hes not around anymore. He was the main guy that knew about that part of the product. Hes missed in EDA support.

[Warren Hinchliffe]

As far as I know it doesnt have the ability to resubmit.

I was thinking of your script the programmer came up with.

So existing process is the same, but the first job gets killed at 60 seconds, freeing up resources.

[Toby Mills]

Oh - I get what youre saying. I could come up with something like that. These jobs that are real lengthy generally all come from one particular domain on the client side. I can aim those jobs to hit a Data Service that has the timeout on it. Good idea.

Ill keep reading

[Toby Mills]

I admit to not reading enough before posting this question, so feel free to point out that this is a simple question that I shouldnt be asking.

Heres the deal at my current customers place.

A Javascript oriented programmer came up with a solution that is watching for a report to be submitted - and then it watches the output window to see if the report returns.

If the report output is not back in like 60 seconds, the javascript automatically re-submits the job as a deferred report. All the parameters are preserved and its basically just re-submitting with IBIMR_defer set to run deferred. The user also gets a note that says their report is running too long, so itll be found in their list of deferred reports.

Heres the problem - they arent also killing the original report thats hogging CPU time on the WFRS. You essentially end up with 2 identical reports (one in the DEFAULT data service and one in DFM_DEFAULT) running at the same time.

Now - as I upgrade us to 8207, Im seeing some problem with their method thats some kind of syntax issue. I bet I can find the syntax error and fix it, but really, I dont think this is the best way to tackle the long running report issue.

Ways we might replace could make use of:

 

 

Resource Governor

 

 

Caster with Library and email notification

 

 

Deferred reports still, but use a dynamically created bat file to edastart -kill to kill the original request.

 

 

Id like to add a button on their selection criteria screens to let them submit as a deferrred or caster report instead of always trying to come back to the browser. I suspect most of these guys that run big reports know that they dont want to wait.

 

 

Does anybody happen to know if Resource Governor can give us this kind of functionality Or do we have to rely on the javascript timeout that notices the output is taking a long time to come back

Just brainstorming with you guys on this. Long report - how to move it to Caster or Deferred processing.

Let me know if you guys have ideas.

[David Beagan]

Seems like something such as the following could work.

Have the report fex produce a hold file from which the final output is displayed. When the user runs, have another fex submit the report fex deferred and then loop every few seconds, checking for the hold file, and if found display the report. If the hold file doesnt show up after a minute, then end it with the message to look for the output in deferred. The deferred version will eventually produce the hold file and report.

Now of course, you could end up with both a report in the browser and stored deferred.

If the hold file could be in foccache that would be convenient, but I dont know if the deferred fex runs in the same browser session or a different session.

[Manoj Chaurasia]

I think something like below will work too:

Add for each request this parameter:

 

&IBIWF_USER_REQUEST_ID=[unique value]

 

and if the report runs more than x-seconds, make a call to the reporting server to kill

that request like so:

 

http://[server]/ibi_apps/WFServletIBIWF_action=STOPREQ&IBIWF_USER_REQUEST_ID=[value]

 

value must match the value as defined in variable &IBIWF_USER_REQUEST_ID.

And then re-submit fex with the DEFERRED parameter

-Fred-

[Toby Mills]

Thanks Fred

The catch to kill the request will be to get the TSCOMID into a variable that the client can use.

That gave me an idea though.

What if I could get the client to know about the TSCOMID and submit the deferred request that contains the long running process running in the DEFAULT data service. Then - make a profile for the DFM_DEFAULT data service that checks to see if a TSCOMID was passed in. If one was passed in, we could kill that TSCOMID with a bat file thats dynamically created.

Im not sure if I can get the HTML launch page to know about the TSCOMID though. Maybe so - I think you get stuck with the same TSCOMID for the duration of your session.

This feels like a good NFR for the EDA guys, but it also sounds like any official solution would be a long way away.

[Manoj Chaurasia]

OK. Understood.

What about the following scenario (Im not sure if it is rock solid, but maybe its worth trying)

Step 1: Make an AJAX call to a procedure that has only the following in it

 

-SET &EDATEMP = TEMPPATH(512, A512);

SET HTMLFORMTYPE=TXT

-HTMLFORM BEGIN

!IBI.AMP.EDATEMP;

-HTMLFORM END

 

Step 2: In the callback function of step 1 strip out the last part, which is your TSCOMID

(value looks something like C:ibisrv82wfsedatempts000001

And in the same callback function submit the report.

As I said not sure if this is rock solid (not sure if you will get the same TSCOMID in the callback if this is running on heavily used server)

Just an idea.

Cheers

-Fred-

[Toby Mills]

Its a good idea. Last I knew, the TEMPPATH subroutine was the only way to figure out the TSCOMID.

I just found a reference to this:

-SET &X=TSCOMID(I5);

-TYPE TSCOMID: &X

Seems to work. I dont think Ive seen that documented, so use at your own risk.

[steve hodos]

Actually, I have stayed in touch with Bruce, if it comes to that (both West Coasties). No, the fellow I was thinking of is Mike Frazier, who was the last guy from Level Five (remember that) still working on RA/RG.

[Toby Mills]

Holy cow - Level 5! Totally lost in my memory till you mentioned it! Wasnt that like our first stab at AI And how long ago was that

I would be curious to know what guys who understand this part of the product would think about the idea of swapping a report out of the DEFAULT data agent and either putting in in DFM_DEFAULT or maybe caster.

So far I cant even find the manuals in 8207 but Ive got my 8206 ones around so I can see pretty current info.

At present, it looks like we can only kill a request and send a message to the user that were killing it custom message. Itd be cooler to let the user know to go looking in Deferred output for their report. Or better would be to give them the option to kill it all together (if for example, they realize that they messed up the selection criteria) OR submit it deferred.

[steve hodos]

Level 5 predates EDA, but thats what they built SmartMode (the precursor to RA and RG) in. In searching Google for doc (because the Tibco site is still terrible for support doc), I ran across this site, which still works! - https://webfocusinfocenter.informationbuilders.com/wfappent/technical-library.html