LargeDoc bizDoc

, ,
1

I’m having a problem where the representation of the LargeDoc indicator is different in the results in Developer that it is in the definition in the pipeline.
Therefore you can never get the value.
pipeline representation - bizdoc/LargeDocument? - where LargeDocument? is a string
results representation - bizdoc/LargeDocument?/MBoolean - where LargeDocument? is a document and MBoolean is the string

Actually I’m seeing this behavior for any variables in the the bizdoc that are boolean, like the following:
bizdoc/ContentParts[0]/LargePart?/MBoolean
bizdoc/Persisted?/MBoolean
bizdoc/LargeDocument?/MBoolean

Anyone seen this behavior before?

TIA

2

Yup. Got nailed by this on the bizdoc/Persisted field (we have logic in our flows to confirm a doc is saved and if not, we force it to be saved). I need to look through some stuff to find how this gets handled and will post what I find.

3

Just what I was afraid of–I’ve code flow services that use both approaches.

BRANCH on ‘/bizdoc/Persisted?/MBoolean’
…false: SEQUENCE (do stuff)

BRANCH on ‘/bizdoc/Persist?’
…true: SEQUENCE (do stuff)

The second style appears to be more prevalent and the most recently used in the services I explored. Sorry I can’t be more definitive. Seems like a trial and error is in order to see which one works in your environment.

4

Rob,

We tried both and neither worked. I ended up BRANCHing on tspace <> $null.
Thanks for taking a look.
Seems like an feature that does not work as documented or just doesn’t work at all. LOL

5

Just getting ready to hit this “feature”. You guys just saved me some painful debugging. Thanks.

Mark

6

I wonder if passing /bizdoc/LargeDocument? to a Java service that converts it from a boolean to a string would do the trick? Shot in the dark. There seems to be many wM-supplied structures that look they are “normal” string/record vars in the pipeline but are actually still Java objects/primitive types–Developer often hides this fact since the results pane does a toString on them. Argh.