Generating schema from record

, ,
1

Sonam,

Since you already have a record definition in wM, use
“pub.schema:createXSD” (I’m using wM ver 4.6) service to generate an xsd. I prefer xsd’s over DTD’s, as they provide greater flexibilty, re: XMLSPY.

When an xsd is used to create a record wM automatically creates a schema definition. For example if you create a record, say record_1, using an xsd, wM creates an entry prefixing the ‘schema_’ before the recordname given. The schema can then be exported thro developer.

Once setup, use “pub.schema:validate” service or setup validation through ‘Document Types’, if using ‘Trading Networks’.

Hope this helps.

Regards,
Conrad

2

Hi Sonam,

Sorry for the delay in replying.

I have just checked and found records created in developer through a schema seem to generate the xsd as required, but not hand coded records, using the same service.
I looked further and found that there are differences in the individual node.ndf files and the record’s field properties, in particular the Content Type (properties - > Constraints).

I haven’t had the time to play around with it. Maybe sometime this week when I have a chance.

Not much of help to you, I guess.

What I normally do is hand code an xml (canonical) in XMLSPY. Generate xsd in xmlspy. Create record in developer by referencing the schema (on my local drive). This not only creates the record, but also a schema with the same name.

Cheers,
Conrad

3

Sonan,

Just a few general comments regarding canonical formats, XSDs, etc:

  1. I would maintain canonical formats as XSD schemas outside of webMethods. You can control different versions of the same document by altering the namespace identifier. Eg. “[url=“http://www.acme.com/docs/purchase-order/2004/02/1”]http://www.acme.com/docs/purchase-order/2004/02/1[/url]”. Next version would be ending with 2 etc.
    It is a very realistic scenario that you’ll have to maintain multiple versions of the same documents.

  2. Use XSDs. There’s no easy way to port a complex XSD to DTDs, unless you do it manually. This is even more pronounced with tools that automatically generate DTDs.

  3. With your schema example generated by webMethods in the last post, this may be caused by the fact that the wM document type references another document type. Maybe you need to generate a schema for the referenced type first, and then manually change the wrapping schema?

I hope you find my comments helpful!

Regards,

Hido

Improve the quality of your services with WmUnit
Unit testing framework for webMethods [url=“http://www.customware.net/wmunit”]http://www.customware.net/wmunit[/url]

4

[Note: this is on 4.6]

Conrad and Hido - Thanks for your inputs.

I found a bug in pub.schema:createXSD where it stop iterating down the record structure if it finds it’s record name mentioned.

I manually created some dummy nested records in IS. The pub.schema:createXSD service worked flawlessly in creating an XSD that iterated down the record structure.

One such records was named “test2” (this is the name which appears in the right hand pane of developer). The structure of “test2” was as follows:

-LEVEL1 (type: record)
–LEVEL2 (type: record)
—LEVEL3 (type: record)
----STRING_UNDER_LEVEL_3 (type: string)

Next, I took all the structure, and indented it under a top-level record named “test2”. So the structure of “test2” now looked like this:

-test2 (type: record)
–LEVEL1 (type: record)
—LEVEL2 (type: record)
----LEVEL3 (type: record)
-----STRING_UNDER_LEVEL_3 (type: string)

This created an invalid XSD that stopped at the top level as I mentioned in post #3 in this thread.

I renamed the “test2” top level record to “test3” so it was now:

-test3 (type: record)
–LEVEL1 (type: record)
—LEVEL2 (type: record)
----LEVEL3 (type: record)
-----STRING_UNDER_LEVEL_3 (type: string)

…and it generated a valid complete XSD once more!

This definitely looks like a bug. I didn’t see mention of this in the Advantage “Fixes to Known Issues for Integration Server 4.6” section.

5

BTW, this bug is only on 4.6 and not on a 6.1 server I tested on.

6

Hello - I was hoping to get some feedback on this feature request I am planning to give to WM. What do you think?

Enable webMethods to function as Source-of-truth for Enterprise-wide Data Structures.

SUMMARY

Definitions of canonical data structures are typically maintained outside webMethods as schemas or DTDs, with tools such as XMLSpy. Maintaining schemas outside webMethods is problematic because changes need to be synced with WM. The process to synchronize these changes with existing webMethods records is manual and error prone.

In places of this process, we want webMethods to serve as source of truth for all data structures used across in the enterprise. We think webMethods is a natural fit for this role. We want to maintain enterprise-wide data structures as webMethods record structures, and export them as schemas or WSDLs. Hence, we need strong schema import/export functionality in WM.

DETAILS

webMethods offers facilities for import and export of XSD schemas - these are the ‘record creation wizard’, and ‘pub.schema:createXSD’ service respectively. However, these facilities need to be made more complete before webMethods can serve as source of truth for data structures.

Some problems with WM schema import:

The import process ignores <xsd:annotation> and <xsd:documentation> elements. Hence documentation is lost.

Schema Constraints are imported, but don’t map directly enough. For example: Schema enumerated values don’t automatically populate picklists for a record element.
Schema patterns such as <xsd:pattern> are imported correctly. However, it is possible to specify a different pattern for a record element, and that overrides the underlying pattern for a schema element.

Some problems with WM schema export:

webMethods ignores record comments (it does not generate <xsd:annotation> and <xsd:documentation> elements during export). Hence documentation is lost.

Schema pattern constraints linked to a record are not exported.
IS 4.6 has a bug in schema export (see above). Also, the same schema exported by 6.x and 4.6 looks different.

The full test of WM providing the requested functionality is when we can import a complex schema into webMethods, then re-export it with no loss of information. (i.e. the imported and exported schema are identical in functionality.)

7

Hello,
I think you have a very thought out request and just make sure your spelling and grammar are proof-read. It is worth submission to WM to see if they are in the works of that already or maybe could take up an outsource help staff to implement it.

My small forward thinking comment:
Would you like to see a seperate editor (outside Developer) still apart of WM that would specifically handle the mass of document creation, export, import and other possible functionalities? Maybe there could be a web front end that would allow you to have a three pane view (import, WM, export) of how WM manages various document schemas. This could be for all definition style formats (DTD, SEF, XSD, etc). They could call it “webMethods eiDefiner”.

Yemi Bedu

8

Thanks for your suggestions Yemi. Sorry for the delay (its difficult to keep track of replies to threads).

I think Developer is the correct editor to edit data structures in. Your post got me thinking about a point (below)… It’s good to continue this discussion.

The current process to create XSDs is pretty suitable to the task. However, in addition to the current import wizard, I would like a service that automates record import.

This service could be called: “pub.schema:import”
It would takes the following inputs:
1 - DTD/XSD/schema (string)
2 - a root node specifier (string)
3 - a folder path to create the new records in (string)
4 - an overwrite/don’t-overwrite setting (true/false).
5 - a check field dependencies setting (true/false)

Input #4 (overwrite flag) is important when refreshing data structures.

Input #5 (check field dependencies) would kick in when input #4 was ‘true’. It would check dependencies of record fields on import by checking if the overwriting an old record caused any of the current mappings in any service to break. (In the current IS dependency checks, IS only shows what top-level service or record uses another, not if anything is going to breaks due to a change).

I submitted the FR to WM, but I’ll ask to have this point added.

9

Hello,
I personally don’t do XML work and only look at it in a conceptual view for how to work with or on it. I am a little confused with your service declaration. You call it import though specify #3 “folder” as a destination along with overwrite/dependecny checks. Is that for the WM side of the import, where your result of transformation will be. I do commend you for actively trying to improve your environment and mine.

So my only other question, what document should I look at to understand your need for this service.

Good day.

Yemi Bedu

10

Thanks for the commendation Yemi. That’s right, this is for the WM side of the import, for when external definitions need reimport into webMethods.

I do not know any other document that better explains this feature request. I am hoping WM finds my description sufficient.

Cheers,
Sonam