I have developed a parallel job and made it RTI enabled using WISD input and output stage. I am using DB2 stages to fetch data from database. The problem is that if I dont pass any parameters to the DB2 stage huge volume of data is selected.. resulting into an abend because of space issues. I am not sure how I can pass parameters to the DB2 stage so that I restrict the amount of data that is selected. Is it possible to pass the value that the user provides through WISD Input Stage to some global variable that can be used anywhere in the job ?
Thanks !
Passing parameters in a RTI enabled job
Re: Passing parameters in a RTI enabled job
How about the User Variable stage? This will allow you to use the variable anywhere within that sequence job.dsscholar wrote:Is it possible to pass the value that the user provides through WISD Input Stage to some global variable that can be used anywhere in the job ?
Thanks !
gateleys
Re: Passing parameters in a RTI enabled job
Thanks for your response ! But I think we can't use WISD within a sequencer. Please let me know if I am mistaken.gateleys wrote:How about the User Variable stage? This will allow you to use the variable anywhere within that sequence job.dsscholar wrote:Is it possible to pass the value that the user provides through WISD Input Stage to some global variable that can be used anywhere in the job ?
Thanks !
Re: Passing parameters in a RTI enabled job
You are right.dsscholar wrote: Thanks for your response ! But I think we can't use WISD within a sequencer. Please let me know if I am mistaken.
1. Write a small function to set user status of a job with any input value -
Code: Select all
FUNCTION SetUserStatus(Arg1)
Call DSSetUserStatus(Arg1)
Ans = Arg1
RETURN(Ans)
3. This way, you can access the user status value (at the job sequence level) and pass it to any downstream job by using JobActivityName.UserStatus.
Note, however, the above method will not allow you to use the param value in the same job. YOu will have to split the job into two.
gateleys
Making the right decision here involves understanding the various topologies availabe in an RTI or WISD Job.....
Job parameters can indeed be passed into an RTI or WISD enabled Job, as input for the SOAP or SOA client, but only when the job does NOT have a WISD input. Then the Job will be invoked on a per request basis, much as you would from the Director, and the values will be passed as appropriate, into a WHERE clause or wherever else you need them. In your case, a DB2 Source....with other stages and then ending in a WISDOutput.......
...however, this is not a good solution when you are looking for a service with potentially high traffic volume (many requests per minute or second, as opposed to a "few per day". In that case, you would probably want an "always on" Job, so that initialization takes place once --- using, as you have, a WISDInput and WISDOutput Stages (or RTIInput/RTIOutput)......and then you simply need to change your approach. Your "parameter" becomes a primary input row running thru the job, and the data you retrieve will be via Lookup. Be sure to set up and test your lookup for multiple returned rows to get the behavior you are looking for.
Ernie
Job parameters can indeed be passed into an RTI or WISD enabled Job, as input for the SOAP or SOA client, but only when the job does NOT have a WISD input. Then the Job will be invoked on a per request basis, much as you would from the Director, and the values will be passed as appropriate, into a WHERE clause or wherever else you need them. In your case, a DB2 Source....with other stages and then ending in a WISDOutput.......
...however, this is not a good solution when you are looking for a service with potentially high traffic volume (many requests per minute or second, as opposed to a "few per day". In that case, you would probably want an "always on" Job, so that initialization takes place once --- using, as you have, a WISDInput and WISDOutput Stages (or RTIInput/RTIOutput)......and then you simply need to change your approach. Your "parameter" becomes a primary input row running thru the job, and the data you retrieve will be via Lookup. Be sure to set up and test your lookup for multiple returned rows to get the behavior you are looking for.
Ernie
Ernie Ostic
blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
...by the way, you can still use Job Parameters in the second job type listed above, but they are initialized when the "always on job" is started... so they would be appropriate for things like tablenames and such, but not for dynamic WHERE clause values.
-e
-e
Ernie Ostic
blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
Thanks for your response Ernie ! We want to create a job that can be triggered from a user screen and it would NOT be getting many requests per min. Selected members would have access to this screen and they would want to run a report once in a while. The user wants the data to be pulled real time, so there is no need for the job to be "always-on" as they are okay to wait for some time before they can see the results. We basically want to integrate DS jobs with java so that the results are shown in more user friendly way.eostic wrote:Making the right decision here involves understanding the various topologies availabe in an RTI or WISD Job.....
Job parameters can indeed be passed into an RTI or WISD enabled Job, as input for the SOAP or SOA client, but only when the job does NOT have a WISD input. Then the Job will be invoked on a per request basis, much as you would from the Director, and the values will be passed as appropriate, into a WHERE clause or wherever else you need them. In your case, a DB2 Source....with other stages and then ending in a WISDOutput.......
...however, this is not a good solution when you are looking for a service with potentially high traffic volume (many requests per minute or second, as opposed to a "few per day". In that case, you would probably want an "always on" Job, so that initialization takes place once --- using, as you have, a WISDInput and WISDOutput Stages (or RTIInput/RTIOutput)......and then you simply need to change your approach. Your "parameter" becomes a primary input row running thru the job, and the data you retrieve will be via Lookup. Be sure to set up and test your lookup for multiple returned rows to get the behavior you are looking for.
Ernie
If I choose not to use WISD Input Stage, how else can I pass the parameters to the job and the DB2 stage?
I am a bit confused about having two jobs... how will i call the second job when the first job finishes ?
Hi dsscholar... (btw ...cool tag name ).
I'm not exactly sure how the discussion has "two jobs" involved, but let me outline the first issue --- Job Parms in a job with WISDOutput...
You could easily design a job like:
ODBCStage -------- Transformer ---------- WISDOutput
Inside the ODBC Stage, you might have some Job parms... #user# perhaps, and more importantly, a value in a WHERE clause for Custom SQL.... WHERE DISTRICT = #mydistrict#.
#user# and #district# become part of the "input" to the Service, they show up in the WSDL, and the java client will send them up..... the WISDOutput can return multiple rows (but be sure to check that you want to return an Array!!!!!!).
This is great for simple, per request services that don't need to be always on. Easy to develop, easy to manage for low volume request traffic.
Server Jobs will load faster, simply by their nature, so if possible I like to use them in these types, although it is not a requirement.
Ernie
I'm not exactly sure how the discussion has "two jobs" involved, but let me outline the first issue --- Job Parms in a job with WISDOutput...
You could easily design a job like:
ODBCStage -------- Transformer ---------- WISDOutput
Inside the ODBC Stage, you might have some Job parms... #user# perhaps, and more importantly, a value in a WHERE clause for Custom SQL.... WHERE DISTRICT = #mydistrict#.
#user# and #district# become part of the "input" to the Service, they show up in the WSDL, and the java client will send them up..... the WISDOutput can return multiple rows (but be sure to check that you want to return an Array!!!!!!).
This is great for simple, per request services that don't need to be always on. Easy to develop, easy to manage for low volume request traffic.
Server Jobs will load faster, simply by their nature, so if possible I like to use them in these types, although it is not a requirement.
Ernie
Ernie Ostic
blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>