Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X

JSON Interface to CREO - Intro


JSON Interface to CREO - Intro

Just as an update.

The site is now up for the introduction of what CREOSON is and how it basically works.

CREOSON - OpenSource Automation Interface for PTC's CREO Parametric!

We are looking forward to your feedback.  The example shown on the site is a prototype interface for Node.js Applications to demonstrate the core principles of remotely manipulating CREO Parametric. The same principles apply to any language (or scripting environment) you want to use.

NOTE: This has NOTHING to do with PTC.  It is an OpenSource project using code we have developed and shipped over the last 10+ years.  So please don't call PTC for support on this, they will not help you.

If you want to help this project move forward, there is a list of things we would like input on... Fill out the Google Form at the base of the site page.  The site will be eventually replaced with something more worthy of handing development / documentation / education in the future.

Thanks in advance!



Where can I find source ?

We are currently working through the details of "how" to properly OpenSource this... if you have any suggestions please throw them out.  We "may" release a Node.js module also to play with at the same time (depends on our workload).  But Javascript and Node.js are VERY popular these days - very flexible.  But that stack has its own issues and learning curve.  Other languages (e.g. php, Ruby, Python, etc...) may be easier for people to use and learn.  <--- THIS is what I am specifically excited about, I think people are going to come up with some amazing things using other languages and integrations that we have not thought about.

We think that GitHub would be the primary way to go - but it does not have the best "control mechanisms" as far as we can tell to manage things to the resolutions we would like to see.  It is important that no other code get into the distribution that is not tested and/or also OpenSource. Specifically - we are NOT permitted to distribute any PTC Code... so we have to protect/manage that.  Still talking about this internally.  ANY SUGGESTIONS?

The generic JSON microserver and application framework for CREOSON is already developed and we are testing that currently.  The stuff that is missing is purely on our side - churning all the high-level interfaces to take the last 10+ years and make it available via this new JSON interface. We are trying to schedule the work around a commercial release we are behind on (the latest release of Nitro-CELL).

More to come.... Stay tuned. 

Thanks for your interest!

Looks interesting. New, fresh, OPEN SOURCE! But, I have mixed feelings. Maybe it is a little easier then using PTC API, but not very for end users. Hope I'm wrong. In any way it is very good initiative. Good luck!!!

ps: Yes, how to try?

Stay tuned...  We will be pushing forward on this soon... I hope we can get something out there initially within the next few weeks if possible.

We have a LOT of functionality that we have built up over the years... So we may start with the obvious things and then dig deeper into more functions later.

Nice, but what was the reason you did not choose Pro/Toolkit or Object Toolkit?

23-Emerald IV

Both of these toolkits are very expensive and most small companies cannot afford them.  J-Link is included out of the box and requires no extra cost.

Well - being that this is OpenSource .... and the core is written in JAVA.... you *could* add your own functions via a JNI Interface.  There is no reason you could not add an interface to support your own functions - assuming you have the licenses to build the Pro/TOOLKIT / ObjectToolkit libraries and distribute them internally.

Our primary reason for using JLINK started years ago...

  1. everyone had it - typically installed by default with Pro/E / Wildfire / CREO.
  2. asynchronous communication enabled us to "not require Corporate IT department involvement to install/configure software" <--- HUGE!
  3. Java was less code to get down the road than Pro/TOOLKIT (back when we started writing our core interfaces)
  4. Java was pretty much already installed everywhere also.  (but today -- our commercial apps like Nitro-CELL include JAVA with the distribution to remove machine localization and version problems that we came across over the years)
  5. We could do pretty much everything we needed to do, and our customers needed to do, with JLINK for ProE / Wildfire / CREO Automation Purposes...  Our approach and philosophy was waaaay different than the typical Pro/TOOLIT developer's approach to automation that we have seen over the years.  Most of our automation processes have focused on the "flow" of data and regeneration ... not creating everything from scratch like a user does..  So JLINK satisfied our goals in this regard 10+ years ago -- just as it does today.

I think the biggest thing we have learned, and tried to teach our customers over the years... Pro/E / Wildfire / CREO have ALL gotten better and better and better as a modeling and documentation tool.  IF you are planning for change, it will respond and execute properly -- IF you have planned ahead ... specifically the workflow of what data goes in, how and when to produce the desired results.  So we encourage our customers to think about the flow of data and execution -- INSTEAD of what a "user does" to get to the same result.  Specifically - TRUST CREO will do what you tell it to...  When you step back and really look at it that way - things get easier, and are more repeatable and useful.  There are going to be barriers you hit, but that is when you fallback to "how does a user fix that issue?"


Years ago I was talking to some corp Pro/TOOLKIT developers about our interfaces and how we do things.  One example that came up was to "update all the parameters in every part of a large assembly"....

I asked them "how would you do this?' -- the answers mostly came back -- "open the assembly, walk the tree, look for a part, process each part you find during the walk, keep track of each part processed and skip them if they come up again."

My response confounded them... "NO!  Open the assembly, get all the parts from memory, process each part... regenerate the assembly.  DONE!"

They sat there dumbfounded for a sec.  Until the lightbulb went off and they realized that they were looking too close at the problem!  They got caught up in the complexity of the Assembly structure on the screen and forgot that all the unique parts were just sitting in memory no need to walk an assembly structure to get to any of them...  just get "what is in memory" and process those!


The above example highlights the approach we fundamentally use for Automation of CREO.  Sometimes the simplest, fastest and most efficient way to do something is NOT to look at the screen.

Hope this is all clear.  Thanks for inspiring a detailed response.

Thank you for this long answer

Nice. Really interested to try it out.

CREOSON Update...

Documentation is one of those critical things that we have always struggled with delivering cleanly and efficiently.  The biggest problem has always been delivering documentation that is easy to find and use - and accurate to what you want to do.

After a bit of thought, and since CREOSON uses a HTTP (Web) Server locally for the JSON Interface to CREO Parametric, we are doing to deliver the documentation via the same HTTP Server.  The documentation will include pretty much everything required to get going and use the JSON API - for the specific version you would download and use.

We thought about hosting the documentation somewhere on the web, but that just seemed like a pain for users in the long run.  Specifically, as new functionality gets added, older distributions may be confused when things don't work properly -- because the user found the latest doc via Google and the current version on their machine is NOT that.  I know, that sounds like "duh" -- but it happens more than you can think.  This is an even bigger problem when inputs/outputs change within an API over time -- something we are striving to avoid.

Here is the current plan:

    Application Services : http://localhost:8000/creoson

    Documentation: http://localhost:8000/doc

This is not final yet, but we are working on it over the next two weeks.  We hope to have an initial beta out soon.  If anyone is interested in being on that short list -- please reach out.