Jump to content
The ibi Community has moved to a new platform: Please Sign In and choose Forgot Password to continue

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


Toby Mills

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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-

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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-

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
  • Create New...