Michael,
Hope you got the nice explanation what you are looking for from Rob,i know this thread will definetely help for basic starters.
Goodluck,
I am having an issue (see attachment) where the behavior seams to indicate that yes, document references are an instance of an object.
In the attached package (IS 6.1) when calling the _TEST_DOC_REF:TEST_CACHED service it repeatedly produces a different result!!! because the cached document reference “instance” (if it is treated like that) changes outside the cached service scope! So every call to the cached service with the same key produces different results.
Calling the inverse example demonstrates that a non document reference behaves differently (correctly!). _TEST_NON_REF:TEST_CACHED
So until proof document references behave like a reference into an object instance.
Regards,
Luis Cordeiro
_TEST_DOC_REF.zip (21.4 KB)
I downloaded the package and tested on 6.5 with SP2. I’ve not been able to duplicate what you observed. The doc returned from both the cached and non-cached services is always the same and is always as expected. The non-reference services behave the same way. What version of IS are you using?
I’ll clarify my description on documents and document references–and document type declarations.
An IS document type is a simply a definition. It describes the fields of a document. The document type is used primarily at design/debug time by Developer. It is (optionally) used at run-time by services that perform validation and conversion to/from IS documents. For example, the document type name is passed as parameter to xmlNodeToDocument or pub.schema:validate.
An IS document is an instance of an object (a class which implements the IData interface). The pipeline var is a pointer to that object (it’s a classic Java var). It contains fields which are either primitive data types or are also documents. Change one of the fields of the object, through any reference var, and the change is reflected appropriately for all those references. But this has no connection to IS document references. An IS document has no connection to an IS document type–even if that document was created through the design-time use of a document reference. This is why we have to explicitly pass the document type name to various services.
An IS document reference is a declaration of a named variable that refers to an IS document type. This is purely a design-time/Developer association. Developer knows that a var is related to a document type, so it shows that relationship. But that doesn’t change the nature of the variable. The variable is still a reference to a Java object. And that variable and Java object have no idea about the IS document reference. If it did, we wouldn’t have to pass the IS document type name to documentToXMLString–it would already know.
As further evidence of no connection between a document var and document reference, create an arbitrary XML string. Pass that to xmlStringToXMLNode and the resulting node to xmlNodeToDocument (don’t specify a documentTypeName). Map the output document to any document reference variable. No errors. No issues. And you’ll see the document reflects the fields and structure of the XML string, not the IS document type referred to by the reference.
The vars in the pipeline behave, as all Java vars do, as references. This would explain the behavior you’re apparently seeing (which seems to be a bug of some sort). But this behavior has nothing to do with IS document references.
Thanks for your reply Reamon.
My IS is 6.1.
I have opened an SR with SAG in the meantime, but I will try this on other 6.1 instalations and on a 7.1 also.
I’ll post the results.
Hi All,
We are working on parsing/validating an XML file that is specific to our partner. It has SOAP data in the XML file. We are trying to create a document type for the XML file but not able to get the complete structure. Please help in getting the document type created for this XML.
All xsd files are depending on references like as in screen shot,
Please help here
Hi,
where are the XSDs stored?
Do you have them locally available or are the located on a remote server?
There are two options for importing the XSDs to generate the document structure:
- generate from top level XSD and have it creating the intermediate schemata on the fly.
- generate the intermediate schemata from their XSD first and then create the document from the top level XSD.
Regards,
Holger
Thank you for reply Holger,
we have stored in local system and i have generated top level XSD’s but it’s showing depending references and different depending name speaces . like as,
Hi,
I cannot see any error or problem here.
Can you explain what issue do you encounter?
Regards,
Holger
Hi Holger,
We were working on parsing/validating an XML file that is specific to our partner provided different XSD (around 200 reference xsd’s. all XSD format GIMA format ). But we haven’t GIMA format imported in Designer and It has SOAP data in the XML file. We are trying to create a document type for the XML(XSD also) file but not able to get the complete structure. we didn’t import GIMA format XSD.
Hi Vara,
you will have to import all XSDs to resolve the complete structure either implicit or explicit.
When you are using LocalServiceDevelopment you can import from your local development.
Pleaaste note the schemaLocation in the import tag should contain “./name-of-imported-schema.xsd” to indicate that it can be found in the same directory as the top level xsd.
If LocalServiceDevelopment is not available you should either import the XSDs from an URL pointing to the partner side storage location or to a Tomcat (as example) running on the same box as the IntegrationServer where the XSDs are stored under webapps/ROOT/.
Fields whose name start with an “@”-sign are attributes for the field above and not child elenents.
Regards,
Holger
Hi Holger,
Thank you for your inputs,
Please find the attached sample files for GIMA XSD’s. just i mentioned root and child GIMA xsd’s,
I have change partner names in attached files.
Please help here on this. we didn’t parsing in Gima format in webMethods.
GIMA request.xml (3.36 KB)
subroot.xsd (3.6 KB)
root.xsd (1.34 KB)
Hi Vara,
are there any messages in server.log or eror log when you try to import the schema files pointing to missing imported XSDs?
If so, can you provide us these?
Regards,
Holger
Hi Vara,
can please post a list of the content of the doc folder if possible?
This will help us to identify what was already generated and what is missing.
The Elements under ActorRoot appear to be geerated somehow but without content (at least partially).
Tths might due to the fact that XSD for these document types was not available during generation.
Regards,
Holger
Could you please send me your mail Id . I will send separately
My mail id varadharajulareddy@gmail.com
Hi Vara,
Can you post the list on my wall plase?
Regards,
Holger