Passing parameters in a RTI enabled job

[dsscholar]

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 !

[gateleys]

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 !

How about the User Variable stage? This will allow you to use the variable anywhere within that sequence job.

[dsscholar]

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 !

How about the User Variable stage? This will allow you to use the variable anywhere within that sequence 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]

Thanks for your response ! But I think we can't use WISD within a sequencer. Please let me know if I am mistaken.

You are right.

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)

2. Now, pass the parameter value from WISD to the above function in the Xfmr. You can call the function as SetUserStatus(YourParamValue).
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.

[eostic]

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

[eostic]

...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

[dsscholar]

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

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.

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 ?

[eostic]

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