Skip to main content
M
MatthewHoover1-Visitor
1-Visitor
January 8, 2011
Question

Windchill API

  • January 8, 2011
  • 11 replies
  • 4737 views

I have struggled with the API/Documentation of windchill's code since I started working with Windchill 9.1.

Maybe i have missed something along the way. The API that is supplied by PTC is lacking at best. It misses some of the main functions that are needed in order to do any deep customization. It leaves out many of the Beans for JSP editing as well as other main packages.

It is almost better to just start guessing in eclipse\NetBeans as to what package may help solve this issue. If all else fails you can try and put a tech support call that may help resolve the issue, but it seems they are in the same boat. Guessing until they give up and say it cant be done, only to find out later that it can infact be done by some "unsupported" method.

The rose model has helped me in places and is a better representation of the code(diagrams as to what links to what) but it still lacks the API feel. It cannot be easily search(in IE) and can be a lengthy process if you are just taking shots in the dark.

It does, however, gives a basic idea of what fields are contained in that item type and is better than the API for the most part, but it only covers the wt folder. While this is the main portion of the coding there are many important methods in the com folder it leaves out. Also in an IDE you can find this same information out just as quickly.

I have to be missing something. Where is the real API? The one the coders at PTC must be using.

Has anyone come across such documentation? Is there a free third party website that i have overlooked?

Any information as to the lost API would be helpful.

Thanks

11 replies

Show previous replies
D
ddemay1-Visitor
1-Visitor
January 11, 2011
It just means, plain and simple, you are on your own. What hasn't been said
is *sometimes* it is possible to pull code from earlier releases to maintain
backward compatibility. Especially if all it does is query and prepare data
the way you want. i.e a case might be a class is refactored or renamed. If
a newer version of same class exists, but the method does not, then you need
to think it through. The response you posted earlier on the team question
is a good thing to point out. Many 'Helper' classes like TeamHelper exist
and wind up called a StandardxxxxxxxxService class method. That alone allows
you to search the code and packages for these. Most are basic queryspec
functionality.



All said, there are many classes that just never change. The tool doesn't
change enough to warrant changing them. Your basic queryspec, queryresult
and persistencehelper type of code has not changed since 6.2.6. That is
true for quite a lot of other code. You get however an occasional big
change to fairly standard code such as when moving from 8 to 9 and change
objects went from managed interface to indirectly implementing Versioned and
possessing a VersionIdentifier. Given the fair warning time you have
considering more then just the code changes it takes to upgrade a system,
there is usually PLENTY of time to fix any issues with code between
upgrades.



The only sage advice I can give is this. NEVER and I mean NEVER put
unsupported API code directly into a workflow or transition in a workflow.
If you must invoke it do so from your own wrapper class external to the
workflow.






Terms & ConditionsAccessibility statement