DSXchange

I have absolutely no idea. Would have to turn to someone who knows what that APT variable does. Do things like try a Server Job and see what happens. Uncheck validation (you don't need xsd validation for this) and see what happens. What are you sending to the stage? --- a URL pointing to XML, or the...

Never heard of it......let us know what you find out. Thanks for the link...

Ernie

Interesting discovery...what happens when you set the value the same in both servers?

Ernie

well, well....surprise, surprise.......I dug up an old job that tests this..... and in 8.5, in a Server Job, "not well formed" xml went down the reject link just fine! :) I did not check validation, and had "REJECT" for all three of the options on the xmlInput Stage. The content ...

Your issue is "not well formed" as opposed to "invalid". Not sure if the Stage can do that one without aborting the job, since it is a more serious failure. Been a long time since I've tried one, but I'll see if I can dig up some old validation tests.......you may have to use a s...

Hi Ray...

Was in FastTrack today for other reasons, and was able to do a successful export at the project level <projectName>.ftp. Worked fine, creating a valid .isx.

Will try a mapping spec next.

This is in an 8.5 running on xp.

Ernie

The XML Stages are fairly consistent from release 6.5, when they were available as an add-on, up until 8.1, with FP1. The behavior, usage, features remain mostly constant, although in 8.0 there were numerous anomalies --- you need at least 8.1 with FP1 to have things fully operational in the 8.x env...

As far as I know, there is no way to restrict a user to "read only" access.

Ernie

In addition to Sreeni's thoughts, what is making your document invalid? Is it not even well formed, or is it just subtly invalid? If it is subtly invalid, uncheck the validation option --- the job should run perfectly. You should probably do both --- check for absolute failures in a sequence or othe...

Could be a variety of things going on. Just for structure's sake, I would suggest entirely removing the namespaces (just zap then in an editor in a small test document), then having a single column for CharacteristicValue and end the xpath with it (fill in the higher elements) .../.../Characteristic...

Then the right approach is Shared Containers. This is a re-usable bit of DataStage logic where you would basically put just your CASS details.....and then use that Shared Container in another Job that has ISDinput and ISDoutput --- and deploy that Job for your users.... ...and include the Shared Con...

Generate a simple DS Job, then go into the target and use the ddl creation option inside of DS to get the SQL. That's a lot of GUI effort, but it should work. Probably easier to just export the mapping and its components and generate your own CREATE from the columns. You could programmatically dump ...

One of the key points in the discussion above is "why web services"? If you are processing files, and you have control...just use files. Please outline the reason for adding web services to this architecture. Then it may be easier to understand your goals and provide the best guidance. Ernie

FastTrack in 8.5 has audit history that from what I can tell, is very complete on telling me who changed what and what the change was..... I haven't experimented with every single possible change use case, but it looks like it might fit your requirements.

Ernie

Let me be more clear in the first sentence.... Save the ISD "Always on" paradigm [ISDInput Stage starting the Job] for your address validation Jobs.....and instead, as outlined in the rest of the post, use a regular "batch" DataStage Job that is published as a Service.

Ernie