We having problems building OAG8.0 Canonicals in wM6.0. As we build the documents using xsd’s, the small element document_types are built for each xsd. If there is duplication, it seems that the elements within each document_type are duplicated. This results in a canonical with multiple references for the same fields.
Any suggestions?
Thanks

wM acknowledges they have problems supporting OAG 8.0. We are attempting to use OAG 8 as well. What we will probably end up doing is generating the DTDs and using those.

We have discussed OAG 8.0 w/webMethods also. The DTD method is the only real workaround available. webMethods also has some issues with multiple namespaces as well as handling substitution groups.

Does anyone know if webMethods really handles schemas as defined by W3C? They seem to be missing some things.

I’m sorry, I have no answer. I just find that a product which is characterized as an xml-based application server has such pathetic support for XML standards. I had what I thought was a rather bright idea. To do schemas outside of Developer (which is a ridiculous endeavor inside of Developer), and import them. It was rather disappointing to see webMethods destroy the careful relationships I had established.

One will quickly find that if you want to anything besides connect dots to existing webMethods services, which one may note, webMethods almost always develops in Java rather than Flow, one will run into endless headaches and work-arounds.

Further investigation has revealed that some of these issues will be supported in later webMethods versions. Possibly in Jan 04 release of Wm 6.1

In response to “webMethods almost always develops in Java rather than Flow”. Generally the core services in IS are implemented in Java. Layered products are a mix of Java and Flow. Applications written by PS folks are mostly Flow. Nothing surprising or secret there.

Please share your “headaches and work-arounds” on the Advantage forums, so solutions can be incorporated in future releases - PMs do regularly monitor those forums.

Thanks,
Fred

I think we all know by now that wM does not support OAGIS8.0 fully. And unless we move to the DTD approach or use an external parser we cannot move ahead with using OAGIS 8.0 and webMethods IS 6.0.1.

One question to Nicolas Lira is are you implementing the work around with the DTDs or you are just looking at that option right now ??

The question that remains to be asked to the group is -
Is there any other workarounds or solutions implemented for OAGIS 8.0 and webMethods 6.0.1 combination ??

Thanks and Regards,
Bala

We are using v7.2.1 for canoicals and works fine with 6.0.1.

Balachandar,
We will try to use the XSDs where we can but if any particular one does not work, we will go with the DTD.

Regards

Nic

It is a fact that wM have limitation handling complex schema like OAGIS which contains multiple namespace, anonymous node, ambiguous node, and overlays. wM’s IData won’t be able to represent these schema characteristic. You can look into a data transformation tool like Contivo which can handle these complex schema and it generate java transformation for wM.

I have just tried creating documents from the OAGIS8.0 Schema’s using Wm 6.1 but I still receive errors. It seems that WM has problems with the recursive nature in some of the schemas.

Strange thing is when I try to make a document type ProcessPurchaseOrder the recursive problems arise with element Location. When I documentize Location I don’t receive an error, and can see the recursive relation.

How can I convert schema’s to DTD’s? Is it done by the hand using XMLSpy for example or is there a automated solution?

I’ve not tried webMethods 6.1, but in 6.0.1 we ended up recreating the OAGIS documents in webMethods by hand. We also decided not to recreate the entire structure of the documents, since Developer slowed to a crawl when attempting to display a canonical with lots of nested references to other documents.

It seems that we have created a valid OAG package from xsd’s. The trick is to create the first document and then RELOAD the package (done either from the Administrator page or from Developer). As a note, we created all of the docs in a “docs” folder and then moved the high-level canonicals out into a “canonicals” folder for easier reference.

GoodLuck

Hi J.J. - Can you expand on what you mean by “The trick is to create the first Document”? Did this approach allow you to import the OAGIS 8.0 schemas or the resulting XML instances into Developer?

Thanks,
Rajesh

Guys,

I’m also interested in using the OAGIS standard as my set of canonicals. After some research, I found the wM_OAGIS8 sample on the Advantage site and I was excited as I thought most of the work of importing the OAGIS XSDs into a webMethods format had already been done. However, upon installing the package, I found out that the package did not contain ANY webMethods Documents. I then figured that the XML schemas within the package must had been modified so that they could be successfully imported into webMethods Developer, but as soon as I tried to import one of the BODs, I received the “recursive” error.

I was wondering:

1. Do you know what the purpose of this sample package is given that it does not provide any pre-created documents or “importable” XSDs? I mean, what good is it? I’ve tried to ask webMethods this question, but they told me they don’t support sample packages.
2. Have any of you made any successful use of this sample package? If so, how?

Thanks,
Percio

Percio,

What version of WM are you using? I’ve researched the OAGIS documents. While webMethods has a sample package, as of Wm 6.01 WM doesn’t support all the functionality of the OAGIS schemas. If you put all the bods into the same directory, that may allow you to import the the xsd. We tried to implement this and found this issue to broad to continue.

Not sure if 6.1 is any better.

Regards,
Jim

Jim,

I’m running webMethods 6.1 SP 1, so it doesn’t appear that 6.1 is any better. I’m just confused as to why webMethods would provide a samples package that doesn’t seem to help any. I must not be understanding their vision of how this package is to be used.

In any case, given that you abandoned the approach of importing OAGIS into webMethods, what alternate path did you take?

Thanks,
Percio

Percio,

Our client abandon OAGIS. You can try this but I don’t recall the results. The biggest issue was in namespaces and using relative paths within the schemas. Try putting all the bods in the same directory. This may work. I think.

HTH,
Jim

Putting all the BODS in the same directory has worked for me with OAGIS 7.2.1

Hi, my name is Jessica. I have downloaded all the OAGIS 8.0 from this website [url=“http://www.openapplications.org/downloads/oagidownloads.htm”]http://www.openapplications.org/downloads/oagidownloads.htm[/url] and I am looking for an example on BOD for customers but there is no BOD sample on that. Do you all have any ideas where I can find such samples? Thank you

Hi Jessica,

In OAGIS, a customer is a subtype of ‘Contact’.

Take a look at Components.xsd

Regards

Correction…

In OAGIS 7, customer is a subtype of ‘Partner’ (for example, ‘ShipTo’).

In OAGIS 8, customer is a subtype of ‘Party’ (for example, ‘ShipToParty’).

Did any one try using OAGIS 9.0.
I am trying to install document type in webMethods 6.1
but i cant it asking for dependable XSD which is already in the folder.
I am using process_purchase_order.xsd schema.

is OAGIS is better then other canonicals ?

any help is highly appreciated

Hi kk - Your question about whether OAGIS is a better standards body than others is a rather tough one to answer. As for your first point, could it be that the BOD that you’re loading into Developer requires support for recursive XML elements? Unless that has changed since 12/2004, wM doesn’t allow you to load XML schemas that have recursive elements.

• Rajesh

Thanks Rajesh & Alan,

I am trying to load process purchase order.xsd and webMethods could not compile giving me following error …

Couldn’t compile

com.wm.util.LocalizedException: [ISC.0082.9805] The system cannot find Resources\Components\CoreComponents\UnqualifiedDataTypes.xsd

I already have Resource folder and there is UnqualifiedDataTypes.xsd present exactly same folder structure as we see in the Error.
Is there any way to resolve this dependencies?

Thanks a lot.

Alan,
Issue #1 and #2 should only surface after converting an XML tree to an IData, which is a much simplier data structure than an XML DOM - one that although far from perfect, is good at modeling XML, EDI, FlatFile, DBMS and other kinds of data. I believe the deficiencies you correctly note can be avoided:

1. You should be able to validate the XML parse tree (the “node” object) against it’s schema before converting to an IData. If there are XSD constructs not correctly supported against the parse tree, they should be reported as bugs.

2. When converting to an IData there are options to documentToRecord to retain order as defined in #2. The default behavior is to roll up duplicate elements into an array because that is a convienent data structure to work with and most documents do not have implied semantics based on multiple-element ordering (I would go as far as saying a document that does is legal based on an XSD, but poorly defined. An example of this poor design is in the flow.xml file format. If I only knew six years ago what I know now, I could simplify the flow loader. ;-)). Also queryDocument can be used to pull out the order dependent elements into an IData format that retains the ordering.

kk,

I did see a package of OAG schemas already imported here:
[url=“http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?w=0&targChanId=knowledgebase&oid=1611998181”]http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?w=0&targChanId=knowledgebase&oid=1611998181[/url]
but I do not know if it specifically has the PO in it. The problem you are experiencing is because of a bug with the webM XSD parser handling multiple levels of relative XSD import paths. The current working directory was not reset after the first import, therefore, when the second file imports a third XSD the relative path was resolved based on the first XSD’s directory, which breaks when there are lots of imports in the complex directory structure OAG ships with. This package was created by re-orging the directory tree. I’m not sure if this bug is fixed in the Integration Server 6.5 release.

Cheers,
Fred