Can anyone please provide some sample code of RTI_TASK_SUBMIT and/or RTI_TASK_SCHEDULER (for 9.4.2).

Thanks in advance.

Do you have a copy of the inet_pdf_example function in your system?

Don Bakke

SRP Computer Solutions, Inc.

Hi Don

Thanks for your response. Yes we have a copy of inet_pdf_example, but I hadn't noticed it before. We thought the INET stuff was obsolete so had overlooked it, but it was very interesting. Thank you.

However, it relies on CallType = . We were more interested in CallType = 0 or 1. We are finding the documentation a bit hard to follow. It seems that an extra parameter "taskdetails" may be required after funcname but what is supposed to contain is not clear. The documentation for RTI_TASK_SCHEDULER also refers to a "taskdetails" but we are a bit foxed about some of the details. For example, its not immediately obvious what "<7> Command to pass " is supposed to contain. is there any sample code for CallType = 0 or 1? Cheers BJ </QUOTE> —- === At 05 DEC 2019 08:04AM bshumsky wrote: === <QUOTE> <QUOTE>Can anyone please provide some sample code of RTI_TASK_SUBMIT and/or RTI_TASK_SCHEDULER (for 9.4.2). Thanks in advance.</QUOTE> First, let's separate RTI_TASK_SUBMIT from RTI_TASK_SCHEDULER. They do "kind of" the same thing, but in very different ways, so - despite the naming similarity - it's best not to consider them together. RTI_TASK_SUBMIT sends in a task to be run by an instance of OpenInsight. It has a few different modes - it can take your request and start up a new copy of OI, run the request, and then terminate the OI; or it can have a "queue" and one (or more) copies of OI that run to service that queue. In all cases, the "task" that we refer to is a stored procedure function (note: it MUST be a function), and it is typically used to run things that require a "UI context" - so, generally, for reports/pdf generation/etc. Capsule summary: it's all managed by OI, and runs OI "stuff" that you want to have run in a separate instance. RTI_TASK_SCHEDULER, on the other hand, builds a Windows task to perform repetitively. This Windows task (as managed by the Windows task manager) calls into the Engine Server and has an OEngine run the request. In these cases, the "request" is a stored procedure SUBROUTINE (not a function), and must NOT require a UI context - so, for example, things like index updating, or other file management. Capsule summary: it's managed by Windows (except for the initial setup, which is what RTI_TASK_SCHEDULER does for you), and it's run in an OEngine. Some confusion may come in to play when, for example, you're running something in an OEngine that needs to generate output like a PDF. Since PDFs require a UI context in 9.4, you might have your Windows task (generated by an RTI_TASK_SCHEDULER call) or your INET or O4W routine (O4W and INET processes run in an OEngine via OECGI) call RTI_TASK_SUBMIT to run an OI to generate the PDF. So…hopefully that's helped clarify (a bit) the difference between the two sets of functions. With that information in hand, what are you actually trying to achieve? Which is the function that you actually need to achieve it? - Bryan Shumsky Revelation Software, Inc. </QUOTE> —- === At 05 DEC 2019 04:02PM BJ Ray wrote: === <QUOTE>Hi Bryan Thanks for the info. We would like to create a batch of files for export (not necessarily .pdf). We have a Subroutine that creates a file. Let's call it FILE_EXPORT. We therefore wish to call this program once for each file. I presume this program needs to be a Function. That being the case, what is it supposed to return? We would therefore like to use the RTI_TASK_SUBMIT to put the requested exports into the queue and in due course process the queue. We would like to use either callType = 0 or callType = 1 and are looking for some sample code that uses this parameter. Looking at the online documentation for RTI_TASK_SUBMIT, there is a passing reference to a parameter called "taskdetails" but are not sure what this should contain. I note the sample code referred to by Don uses callType = and that does not pass "taskDetails".

Thanks

BJ

We would like to create a batch of files for export (not necessarily .pdf).

So two questions come out of this:

1. Are these generated regularly, on a regularly scheduled basis (for example, every morning at 8am)?

2. Are the output files using OIPI or anything requiring a UI context at all?

If the answer to #1 is YES and #2 is NO, then you would probably be better off setting up a Windows scheduled task with RTI_TASK_SCHEDULER. But if that's not the case, then RTI_TASK_SUBMIT is what you'd use.

We have a Subroutine that creates a file. Let's call it FILE_EXPORT. We therefore wish to call this program once for each file. I presume this program needs to be a Function. That being the case, what is it supposed to return?

The way that RTI_TASK_SUBMIT was designed, the "submitting" routine was supposed to send in its request ("Run this stored procedure" ) which would return for you a "task id". You can then query (via RTI_TASK_STATUS) to see when the job is done, by passing in that task id. What's returned by RTI_TASK_STATUS is a status (which will be COMPLETED when the routine has finished running), and the second parameter of the RTI_TASK_STATUS call will be the return result of the invoked stored procedure; so for example, maybe your FILE_EXPORT routine should return the file path and file name of the exported file? Then you could show that to the user (if they were waiting around for the job to complete)…?

We would therefore like to use the RTI_TASK_SUBMIT to put the requested exports into the queue and in due course process the queue. We would like to use either callType = 0 or callType = 1 and are looking for some sample code that uses this parameter.

Looking at the online documentation for RTI_TASK_SUBMIT, there is a passing reference to a parameter called "taskdetails" but are not sure what this should contain. I note the sample code referred to by Don uses callType = '' and that does not pass "taskDetails".

I'm not sure where you're seeing the "task details" in the help - on my copy (admittedly, it's OI 10), I have the on-line help showing the parameters as:

Rslt = RTI_TASK_SUBMIT(callType, funcName {,<param1>} {,<param2>}… {,<param10>} )

In this case (which is still what your copy of OI will use, even if it's running 9.4.x), you would pass in the type of call (0/1/null), the name of the function (FILE_EXPORT, or if you modify it to be a function, maybe you'll rename it FILE_EXPORT_FUNCTION), and then any parameters that FILE_EXPORT_FUNCTION needs to have passed in for it to run. Maybe the first parameter to FILE_EXPORT/FILE_EXPORT_FUNCTION is the file path where you want the data created, and the second parameter to FILE_EXPORT/FILE_EXPORT_FUNCTION is the type of output (CSV, PDF, etc.). So if you were running the FILE_EXPORT routine from inside another program directly, it might look like this:

CALL FILE_EXPORT("C:\TEMP", "PDF" )

OK so far? Well, then, to run it via RTI_TASK_SUBMIT, you'd issue a command like this:

DECLARE FUNCTION RTI_TASK_SUBMIT

taskID=RTI_TASK_SUBMIT("", "FILE_EXPORT_FUNCTION","C:\TEMP","PDF" )

The remaining question, then, is what should "calltype" be? It's going to depend on how you want to run this background queue. If you want to have a queue that's always running, and when new requests are submitted it will "grab" them and process them, keeping one (or potentially more) OpenInsight instances running to manage this, then you can choose callType 0 or callType 1. The difference is that with callType 1, RTI_TASK_SUBMIT will start up the "queue manager" if it's not already running; with callType 0, RTI_TASK_SUBMIT just "assumes" that the queue manager is already running, and YOU must have started it with the RTI_TASK_STARTUP command.

Calltype null ( "" ) means that you don't want to have the queue manager running, you don't want to dedicate some OpenInsight instances to running all the time to run these background requests; instead, you want to just spin up a copy of OpenInsight to run this specific task, and then have it terminate.

So to summarize:

Calltype "": Don't really run a "queue", just start an OI, run this request, and terminate;

Calltype 0: The queue manager has already been started, so just add this to the queue for processing when there's a free instance;

Calltype 1: Start the queue manager if needed, and then put this request into the queue for processing when there's a free instance

(Note: Look at the online help for RTI_TASKMANAGER to see how you can configure the number of OpenInsight instances that should be used for queue processing, if you choose to use CallType 0 or 1 )

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

I'm not sure where you're seeing the "task details" in the help - on my copy (admittedly, it's OI 10), I have the on-line help showing the parameters as:…

The following is in the online help in OI 9.4.2. listing the parameters for RTI_TASK_SUBMIT

callType

There are three possible values: null - Launch immediately 0 - Add task to the queue 1 - Add to the queue, launch a poller to process the queue funcName - The name of the fuction or subroutine to execute. taskdetails - An @FM delimited array containing the information to place into the Task Scheduler for the specific job. Used with the ADD tasktype only. {,<param1>} {,<param2>}… {,<param10>} - The arguments for the function. RTI_TASK_SUBMIT supports functions with up to ten arguments.

We have now confirmed that an extra parameter *is* required where "taskdetails" is supposed to go for calltype = 0 or calltype = 1. Again, the question that follows is what is "taskdetails" supposed to contain? We have tested it with a null and it seems to work, although a brief unreadable message is flashed up accompanied by a beep.

Our testing also suggests that <param1>..<param10> does not seem to be support multi-valued parameters. Is this correct?

BJ

Hi, BJ. From what I can tell, it looks like the online help that you quoted is incorrect; indeed, it looks like that line was incorrectly copied from the RTI_TASK_SCHEDULER function, and is not applicable here.

I have looked at the source for RTI_TASK_SUBMIT (in the 9.4.2 version), and it matches the function parameters I described earlier:

Function RTI_Task_Submit( CallType, FuncName, Param1, Param2, Param3, Param4, Param5, Param6, Param7, Param8, Param9, Param10)

There is no "taskdetails" there, and so I cannot tell you WHAT is supposed to go there. I CAN tell you what is supposed to go in the parameters for a call - it's described earlier in this thread.

As to whether or not the parameters may contain value marks - I don't see anything in the code that should "break" if you passed in @VM (or even @FM) delimited data. However, since you normally have control over both the calling routine (the one that's calling RTI_TASK_SUBMIT) and the routine that's called (the routine named "funcName" in the RTI_TASK_SUBMIT call), you could always escape/change these values if they didn't work…?

- Bryan Shumsky

Revelation Software, Inc.

View this thread on the Works forum...