DSXchange

Let us know what release of "8"........ .1, .5, .7 ?

...And does it occur with all columns? What stages does the column pass thru in Job2?

Ernie

Does this mean that you have resolved the problem? I am sorry but I'm not sure I understand what difficulty you are having. Are you getting the multiple address rows per customer as you have outlined? Yes, indeed...if you have multiple repeating nodes they must be mapped to their own links (which is...

....that being said, ISD knows nothing about config files --- that is all abstracted from ISD....it simply starts the Job, and the ISD stages are run at the conductor node...beyond that it has no visibility. ...and as noted before, there is little chance that you need anything more than single node....

99.999 % of all cases with real time jobs, you are going to want a single node config...anything else is total overkill and complicates your support and debugging.

use multiple instances (set inside of ISD) if you want to increase the traffic.

Ernie

It's a long discussion, and there are still some valid reasons to use the older stage.......but here are some key points relative to your initial questions.... a) xml is not relational.....ETL tools and rdbms' are. The natural place that they match up is in xml's repeating nodes....where each repeat...

Exactly. This is the normal default behavior for either XML Stage parsing step or the xmlInput Stage. In xmlInput Stage, make one of the address fields a key..... If in the output step of the new xml stage, make your first mapping effort a drag of the address "list node" to the output link...

Great reference! Thanks!

key doesn't mean much in the case of the new stage. If you are parsing, the key here will be the way that you perform the mappings in the output step. I can't exactly understand what your scenario is, but here is a golden rule to follow in the output step: ...decide which "node" in the par...

there's no way to measure that as a simple "one or the other"...available skills, available jobs, etc. etc. etc. etc. have to be brought into such an evaluation.

You can build tags any way that you want...there is no restriction.

Ernie

You'll need to be more specific...the doc, hundreds of posts in here, etc. have lots of basics. What problems are you having?

Ernie

1. Use only "sparse" lookups for ISD based Jobs. Otherwise you will not get updates...there is no refresh, and you wouldn't want one because that could take a long time. 2. The aggregator works fine because it is all based on "end of wave"....meaning that each "request"...

Indeed...write your own widget that takes advantage of the BG REST API. This is a very functional API that lets you do searches, retrieval and even updates to the BG if desired. Most sites use it for browse/search. Being a REST based api, it is very palatable to Web and HTTP based developers. Ernie

UMF is verrrrry close to xml. You should be able to use the xmlOutput Stage, especially in "chunk-only" setting, to accomplish most of what you need... Identity Insight, in my experience, is very loose and "generic" with its tag definitions....meaning that you often need things l...

follow the link given up above.

That thread will indeed explain the red circle for you. Let's talk more about your column lineage....there may be some reasons why that might occur.... Look carefully at the ways that your lineage is being established. Is it exclusively via DataStage? Exclusively via Extension Mappings or FastTrack ...