Mapping jar to schema

[johngid]

Is there a way of mapping from the schema4.xsd to the actual jar?, ie a way to know that Entity12 is Person.

[TonyJon]

You should not need to know that Entity 12 in our auto generated Schema jar is Person. The compatible XML that you need to generate is defined by the XSD's and they use the actual names of the entities as defined in the schema. If you make changes to the schema and re generate the mapping jar, you may find that Person is now Entity 13 in our compiled classes. The class names in that jar are just procedurally generated and only for internal use.

[johngid]

Hi Tony, thanks for your reply. I understand the point of when redefining the schema, all of the numbers will change, which is why I was asking for this.

2 years ago, we built some connectors using those classes. We made instances of the objects in the classes, and then converted those to the XML that IAP was expecting. We found that way of doing things to be easy enough to work with, since we didn't have to worry about XML transformations, which in the case of several data sources could be a lot of work.

Is there a plan of having this way of building things again available? Right now, in current connectors, we still work like this, however, we have to unzip the JAR and decompile it to see what kind of entity/link/property/property group it is, and as you said, when we regenerate the schema this work has to be done again.

Perhaps generatting a mapping file that could be used?

[TonyJon]

Hi I can see the value of having library classes to help clients who want to take the annotated java class route to create our XML for ingestion, but that sort of support is not available.

I can also see the allure of doing what you have done.

Working as you are with internal type and property id's however is very brittle and not recommended, you should not be decompiling the mapping classes.

The classes that you decompiled are from our mapping jar that maps the XML that our API's consume to the internal IA items.

As you have seen, XSD files are generated as part of the same process that creates the mapping jar, and these describe the Items you need to generate XML for. You do not need to decompile our classes to see what the XML you need to give us should look like.

So, a better way of doing things is to create your own java classes that are annotated so that they generate the XML we require using the property names and item type names given in the XSD files.

A down side to this is that if you changed the names of the properties or items in the schema designer that you have mapped in this way you would also have to alter your mapping classes, but at least they would not have to be altered just because you re generated the mapping jar and the id's happened to be different.

Depending on how often you expect a schema to change you may decide that you need to invest more in your connector code and make the XML generation code more adaptive .

Theoretically you could write code to auto generate your mapping classes from the XSD's which would make schema changes less of a problem.

Alternatively you could use XSLT to create the XML as many clients do, and you would again be using the XSD's for guidance not our compiled mapping jar classes.