DSXchange

Not sure what you are proposing, unless we are all still mis-understanding the objective. I am under the impression that the goal is to match the actual "documentation string" from the xsd next to each of the possible enumerated values that might be flowing down from an individual instance...

Regardless of how it's done (via xml stages or via xslt), the solution entails parsing the xsd as "actual data" and then providing that information via (probably) lookup, as Craig noted way up above in this thread. There isn't anything automatic that is going to apply the details in the xs...

Another poorly designed xml document. Would have been much nicer if it used a repeating node for "question" with metadata underneath that as an element or attribute with "questionNumber" and a value of 1, 2, 3, etc. I would probably just use the xmlInput Stage and develop the Job...

No one understands exactly what you are looking for.....you say "get metadata from the xsd"......there are all kinds of metadata in an xsd (rules, validation types, namespaces, etc. etc. etc.). ...and as Craig noted above, it isn't clear in the example where you are seeing "Maple"...

My question was ....do "any" xml jobs work on your test installation?

Unfortunately your error is not particularly informative -- hard to say if it is a problem with "this job" and its data, or the stage or the installation in general. Do ANY Jobs with the xml Stage work ok?

Ernie

Most likely, the environments are not the same....all the stuff you need is exported with the Job...the library details, etc. If they are both the same release and same fix pack level, the job should just "work" as with any Job....I've done it many times and had people ship XML based Jobs ...

Off the top of my head, I would instead set this up as an always on job so that I don't have to pass the job parameter at all....the encrypted value will be in the app itself and each invocation will be vastly more efficient. Alternatively, consider using https and ssl for encryption of the entire s...

did you push THAT xml sample thru trang? If so, it will produce the correct syntax for you in an xsd that includes maxOccurs.

Ernie

it's still not entirely clear what you want to do....in order to parse this using "normal" xml parsing methods, the "metadata" is what controls what will be retrieved. In this example using the simple old xmlInput Stage, you would have a column in the link called gn_cd, and it's ...

...by the way....what kinds of SOAP clients are calling your ISD services?

Ernie

Jobs deployed under ISD as services are "multiple instance" and will be started and stopped continually, depending on traffic coming into your application. There are no particular stats in the Designer that you can expect to use...it's not a "batch" job in the common sense. Monit...

...as expected, the instruments declaration in your xsd needs a maxOccurs="unbounded" attribute. Do some searches on the web and you can see where that should be added. It may also be that your original source to your conversion tool didn't have multiple "instrument" nodes in it ...

post your xsd here if it is small, or just the parts of it that talk about the elements that you expect to be delivering multiple rows. Perhaps also post a piece of the xml document itself that contains those rows.

Ernie

Congrats! ....that's not a "workaround" though. . It really is an advanced use of ISD and its settings!

Ernie