A question for those who have used the WebFOCUS client adapt...

[john cullen]

A question for those who have used the WebFOCUS client adaptor.

One of our analyst groups came up with a brilliant requirement to make 1000 schedules.

I could not imagine sitting there cranking out 1000 ReportCaster schedules, so I looked into the Client REST adaptor, create_schedule master. Long story short, I can make schedules for an entire folder of focexecs from a focexec, reading the repositiory, passing the criteria to the REST call.

My problem is, it creates the schedule with Admin as the owner. I dont really want admin to own my schedules. Before anyone asks, yes I did use my userid to run the procedures, but based on the audit log, when you make the rest call, it logs in as Admin.

Do you know any parameter I can pass to the Client REST adaptor, to make the userid the same as &FOCSECUSER I just dont want my schedules to be owned by admin.

My hokey workaround go into admin mode with my userid, publish, unpublish, publish, then I own the schedules. It works, but Id prefer it right the first time.

[Benjamin Kopp 3]

Hi,

you have to change the owner of the schedule, then the execution id for the task will also be the same id as the owner. If you are using the standard master file that can be created through the rest adapter a where statement like IF OWNER EQ &FOCSECUSER.QUOTEDSTRING in your TABLE request should do the trick.

Regards

Ben

[Toby Mills]

Morning John

First, I got a laugh out of their brilliant requirement.

Second, its cool you figured out how to get schedules created using the WF Client adapter. We started playing with the adapter but didnt keep it on our system after we hit some problems in the WFRS where enabling the WF Client adapter caused using a full IBFS://EDA in a stylesheet started failng. Who knows how those 2 things are related The case was never officially resolved.

I saw Bens note above - thats cool if thatll work.

In order to solve the puzzle, one thing Id like to know is - Why does the adapter think and ID called Admin even exists And how did it log on with that The only place I know of that this parameter is rolling around is in the utilities folder in setenvutiluservars. Itd be kind of a stretch, but I wonder if, in the absence of a statement like Ben suggests, if perhaps they default to using utiluservars

Can you think of another place its stored that the adapter could find I suppose you could change your utiluservars just to see if magically you get a different ID.

Otherwise its time to turn on a bunch of traces I suppose. Im not sure which traces to turn on. Theres one thats called com.ibi.rs - wonder if thats REST web services

Let us know if Bens idea works.

Later!

[john cullen]

Bens idea doent work. Its pretty obvious you have to set OWNER, and I did.

The .sch file gets added to the repository with a owner of admin, because if you look in the audit.log, when it makes the webservice call, it is logged as admin. That is the element I am am trying to change. I dont see why the webservice call is made as admin, Im looking for why.

It actually was pretty easy to make schedules. the client rest adaptor has samples. I had to make an amalgamation combining two of the samples. I would read the wf_reposobj, make a list of the fexs to schedule, then loop thru that list making the webservice call. Had a couple of snaggles, like the &parameters could not have any spaces, and Efrin made some of the fields in the create_schedules.mas too short, but all in all, it didnt take long. It certainly beats clicking out 1000 schedules in the reportcaster GUI.

If I find the answer how to make the webservice call as &FOCSECUER instead of Admin, Ill post it.

The workaround of publish, unpublish, publish, isnt a bad workaround, just an extra step.

[Benjamin Kopp 3]

Im sorry that my hint does not work for you. In the environment I currently work in it does work like this. The schedules are created with a specific user as owner and right after that they are published. When they are executed the defined owner id is used as execution id.

Perhaps it has something to do with the user your REST adapter is configured with

[john cullen]

Ben, Yup, thats it webservice will run under the userid on the adaptor. I did use admin there. Ill reset it to password passthru.