Page 1 of 1

need real time scenario

Posted: Tue Oct 28, 2008 8:22 pm
by alex007
hi am alex. i need details in real time how parallel stage will be working, and what is the main difference between server and parallel stage.if any one have knows pls explain the full parallel and server stage how it will be working in real time envoirnment

Posted: Tue Oct 28, 2008 8:40 pm
by ray.wurlod
Welcome aboard. Is this an interview question?

If not, can you give a scenario in the context of which you'd like an answer? There isn't really any "one size fits all" answer.

Posted: Wed Oct 29, 2008 10:59 pm
by John Smith
Hi alex
though there are ways you can make it real time it's real strength is in batch processing. what sort of real time environment do you have?
Must it be real time or can it be near real time meaning micro batches that run every 30 seconds? Like Ray said you need to provide the context.

Also it would be advisable to get some training if you are new to the product.

JS

Posted: Thu Oct 30, 2008 2:14 am
by alex007
yes am now only learning data stage am new to this so i dont know how it will be working in real time.i like to know how the updation will be made in datastage in real time in production in parallel and server enviornment,

Posted: Thu Oct 30, 2008 4:37 pm
by eostic
Ok....so then perhaps you can just tell us more about the real time updates that you are looking at...we can all discuss the DataStage specifics later, as well as the use cases.....

...what is the input? A flat file? A database? a message queue?

Ernie

Posted: Thu Oct 30, 2008 7:40 pm
by alex007
its an database, like ms acess, i like to know if we using parallel enviornment how the update will update in target database.and what the difference between server enviornment target database updation andtarget database updation. in real time take eg like bank they need to update an new column and new datas in target database,in the same time they need to update the new column and new datas all over thier geographical location, in this case what is the job for parallel and server
enviornment how they will updateand what is the difference between the two.what envoirnment make more efficent in updation and why?

Posted: Tue Nov 04, 2008 6:16 pm
by John Smith
alex007 wrote:its an database, like ms acess, i like to know if we using parallel enviornment how the update will update in target database.and what the difference between server enviornment target database updation andtarget database updation. in real time take eg like bank they need to update an new column and new datas in target database,in the same time they need to update the new column and new datas all over thier geographical location, in this case what is the job for parallel and server
enviornment how they will updateand what is the difference between the two.what envoirnment make more efficent in updation and why?
Hi ,

If it is ms access in real time, then forget about using Datastage be it Server or Parellel. And if it is a banking type transactions again don't use Datastage. Your real time application should be developed using a different tool/product.I am surprised with the combination though MS Access and Banking ;) Also surprised that you would use MS Access for a distributed geographical solution...
I must have been lagging behind in the technological advancement of Microsoft...

surely you can't be serious....

JS

Posted: Tue Nov 04, 2008 7:20 pm
by filename.txt
John Smith wrote: And if it is a banking type transactions again don't use Datastage.


Can you please explain us why ? I didn't understand this point.

Posted: Tue Nov 04, 2008 9:33 pm
by John Smith
filename.txt wrote:
John Smith wrote: And if it is a banking type transactions again don't use Datastage.


Can you please explain us why ? I didn't understand this point.
the OP is after a real time transaction system like those used in the banks. DS is good for batch processing not real time transactions.
Sorry for the confusion.

Posted: Tue Nov 04, 2008 9:38 pm
by ray.wurlod
DataStage can be configured to support real-time applications, by exposing a job as a web service through ISD. An always-running, multi-instance job is capable of quickly processing the data sent to it by the caller (and sending data back to the caller).

There is probably insufficient "encryption in flight" in this approach to satisfy the security requirements of most banks, particularly now that the regulators are going to screw this down even tighter.

Posted: Tue Nov 04, 2008 10:10 pm
by John Smith
Here's the IBM web site on using Java for Real Time applications.

http://www.ibm.com/developerworks/java/library/j-rtj1/

I'd happy to be proven wrong but has anyone built any real-time systems for a bank using Datastage?

Posted: Wed Nov 05, 2008 12:52 pm
by eostic
One of the things that has to be looked at carefully here is the specific real time data integration "use case" whose problem needs solving.

Everyone on this thread has said correct things. Would DataStage be used to "build" an entire real time banking system...to be the sole infrastructure of such a system? Nope. Not even close. Might there be a hoard of interfaces to (and from) such a system that could/should use DataStage as a feeder, transformer, batch processor? Absolutely. It (DataStage) is only one piece of the puzzle, as in any environment. So many more details are needed, from target/source scenarios, different integration goals, users and support people, etc.

DataStage can provide real time transformations that are available to the rest of the enterprise and all other applications, and it can provide real time feeds from disparate systems, and it can, when necessary, perform units of work across different tables....but there are pros and cons for using it for each of those things, and technical and non technical variables that impact whether it makes sense in one environment or another.

DataStage has a complementary role to play in any data integration environment --- sometimes for nothing but "real time" purposes......but those purposes and goals have to be qualified with a lot more detail than any of us have heard here.

Ernie