NEW JavaScript / JSON Interface to CREO?!

[DavidBigelow]

Good Day All...

We have been developing a highly optimized interface to Pro/ENGINEER / CREO that uses JLINK (and can also support Pro/TOOLKIT) for many years - it is the core library of our commercial offerings like Nitro-CELL, Nitro-PROGRAM, and Nitro-BOM.

The current code base is a Java Library that can be included in a Java application to directly communicate with Pro/E / CREO asynchronously (control Pro/E / CREO externally - not as a registered application on startup - connects on the fly).  While we have some specialized applications running headless automations for some of our customers using the library directly, most of our code uses a micro-server to handle all the bi-directional traffic to/from CREO for us.

The micro-server basically internet/network-enables an interface to Pro/E / CREO - but is often used on the same machine as the application talking to it.

We have been thinking about implementing a NEW "JSON" layer to the micro-server that would allow ANY language to communicate and run our optimized JLINK interface remotely.

The simplest implementation would be JavaScript in my view.  For a couple of reasons.

1 - tight, efficient and readable code

2 - easy to learn for people new to programming or seasoned pros

3 - LOTs of code out there as examples

4 - active community for help

5 - Node.js as an application framework and service is very popular and easy to use (stand alone applications, web and socket applications and services)

6 - Office 2016/365 is embracing javascript more every day.

7 - There are a lot of libraries and packages available for it...

8 - it is fast, flexible, extensible and cool.

An example of this could be as simple as this:

var requestObj = {

   action : "open",

   parameters : {

       name : "box.prt",

       display : true

   }

}

creoClient(requestObj);

But -- IF (big IF) we build a JSON interface, this would be able to be used by ANY language that supports JSON.... Visual Basic, .NET, C#, Java, etc, etc. etc.  So we feel this would be a good option for anyone - regardless of development preferences

Please respond with any thoughts or interests in this.  Not looking to "sell" this -- it is an interesting idea as a starting point.

Thanks in advance.

[TomasLoun]

Nice, but such an interface can be accessed by multiple clients. How will you solve it?

[DavidBigelow]

Thanks for replying...

Simply put : We Won't, that is up to you.

This is just a box of Legos... You can implement them any way you want and distribute them anyway you want.

CREO is still a single-threaded workflow.  If multiple clients are accessing it, problems are soon to come up for sure.  It is possible to run multiple requests into CREO at the same time - but the changes of screwing up someone else's session is huge (e.g. "erase memory" call affects everyone using the same CREO session, not just your models)

That being stated, we DO have customers that DO have multiple clients requesting CREO to DO things -- e.g. build assemblies headless, batch process changes, etc.  This requires job queuing (job = a defined process that will be called with specific variable inputs/requirements).  Basically a Traffic Cop to manage the process.

This is also why Node.js is (very) attractive as an option (but please note, this can be used by ANYTHING that could communicate via HTTP and JSON).  Node.js specifically can serve two purposes for people that use this:

1. a standalone application / script
2. a server that can act as middleware to handle multiple client requests (queue) with ease

The other HUGE benefit of Node.js - it is one (1) language through and through - JavaScript. 

So your server is written using JavaScript and your Client requests to CREO via our interface would be with JavaScript.  If you wanted to put a Web Page in front of all this to collect user inputs and display information... Node.js can serve that also and all the client functionality there... JavaScript (again).  With a little more work, you can connect to and consume data from other systems via internal (or cloud) services/databases or whatever -- VERY enterprise friendly!

I must reiterate - this is NOT exclusively a "JavaScript Solution" for CREO - it is a HTTP / JSON Solution that ANY Language can leverage.

However, (I believe) this would be easier to use than JLINK or C++ or VB -- less code, more functionally defined expectations and results.  A lot of nice things are already baked into our core interface that are often bload code like "wildcarding" ... for example:

     fileObj = new creoFileObj()

     fileObj.action = "open"

     fileObj.parameters.name = "*.prt"

     fileObj.parameters.display = true

     creoClient(fileObj);

The above command would open every *.prt file that is in the current working directory and display them in CREO as it goes.  Our core layer has been optimized to not just reduce the number of calls you make, but also are also organized into high level categories to the common-sense things you want to get information or manipulate (e.g. model, dimension, parameter, note, feature, etc.)

The result should be a lot less code that is approachable and quick to accomplish impressive things - especially since we quite a few name and value filtering options for most of our CREO operations.

[DavidBigelow · Accepted solution]

GOOD NEWS!

We got permission from PTC to release our language-agnostic JSON Interface/Server as an OpenSource project for -ANY- PTC CREO Parametric Customer interested in automating CREO Parametric.

The new interface will be called "CREOSON" -- (CREO + JSON <-- ha!) and we hope to start releasing the core over the next few months as we figure out the best methods for distribution, code management and documentation.

There are a few stipulations you should be aware of:

1. CREOSON has NOTHING to do with PTC Corporation (So DON'T CALL THEM for any help/questions/support! - seriously).
2. CREOSON must NEVER include/ship/deliver any PTC Software Libraries with the OpenSource CREOSON Package.  This is not a problem because the required libraries PTC is concerned about are already shipped CREO Parametric from PTC (see point 3).  We will moderate the CREOSON changes/releases ensure that any releases only include OpenSource - or properly licensed - libraries/modules/packages/etc.
3. CREOSON REQUIRES PTC's JLINK Interface be installed with CREO Parametric to work.

We are in the process of laying the framework for how to properly roll this out for easy download, usage and contribution.  Be patient - we need to do this as close to right as possible.  One thought is to use Apiary for code documentation/examples - any other suggestions?

NOTE: creoson.com‌‌ will be launching soon. This site still needs to be developed with the right communication framework and examples.  (again, any suggestions welcome!).

Thanks for all the positive feedback and interest that we have received thus far - and also especially to PTC!  It is appreciated!

Dave