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

We are happy to announce the new Windchill Customization board! Learn more.

REST call on WTPart Checkout results in Error

TomazJeras
11-Garnet

REST call on WTPart Checkout results in Error

Hello,

I did some REST 1.5 API tests in Postman and things do look good.

However, I found some problems which I cannot explain. For example, I am unable to do Checkout/Checkin on WTpart.

I created new WTPart and tried to do Checkout via REST call, someting like that:

http://tomazj-wnc11.audax2.local/Windchill/servlet/odata/ProdMgmt/Parts('OR:wt.part.WTPart:1462146')/PTC.CheckOut

Exactly like in Windchill REST Services User’s Guide v1.5, page 167.

I used POST call, I got current CSRF_NONCE.

Return JSON is :

{
"error": {
"code": null,
"message": "The type of the type cast 'PTC.CheckOut' is not defined."
}
}

MS log error is:

2019-06-14 10:58:43,931 ERROR [ajp-nio-127.0.0.1-8010-exec-2] com.ptc.odata.windchill.servlet.WcRestServlet wcadmin - An unexpected REST error occured
Type 'PTC.CheckOut' not found.

 

It looks like there is something wrong with my REST implementation in Windchill. I got v1.5 via 11.0 M030 CPS 15 install.

I authenticate in Windchill as wcadmin.

Any ideas?

Regards.

2019-06-14 13_39_30-Postman.png2019-06-14 13_40_06-Part - WTPART-00099391, TestRestWTPart_001, 1.1 - Internet Explorer.png2019-06-14 13_40_21-10.0.0.170 - Remote Desktop Connection.png

 

1 ACCEPTED SOLUTION

Accepted Solutions

@TomazJeras this is a documentation error, this should be addressed in the next document release. The correct API to use is

http://tomazj-wnc11.audax2.local/Windchill/servlet/odata/ProdMgmt/Parts('OR:wt.part.WTPart:1462146')/PTC.ProdMgmt.CheckOut

View solution in original post

8 REPLIES 8

@TomazJeras this is a documentation error, this should be addressed in the next document release. The correct API to use is

http://tomazj-wnc11.audax2.local/Windchill/servlet/odata/ProdMgmt/Parts('OR:wt.part.WTPart:1462146')/PTC.ProdMgmt.CheckOut

Thanks.

 

Regards,

Tomaz

@amarsingh, is this new in the REST 1.5?  I'm using an ECAD application and we had everything working with REST 1.2.  We needed to upgrade to CPS-15 for some unrelated reasons and now I am seeing the same error messages in the logs from my ECAD application that uses the APIs (instead of using WWGM).  I don't have control over what the ECAD application does, and it looks like it's sending the PTC.CheckOut and I'm getting the same error that TomazJeras had.  Thanks for any feedback that you might have. 

This is rather a documentation gap and an issue. This bound function should be called along with the name space.

Hi,

I checked REST documentation back to v1.0 and Checkout was everywhere mentioned in /PTC domain. I am currently unable to check this for previous REST versions, but it is possible that they moved CO (and CI) commands to ProdMgmt domain in versions since 1.2, but they forgot to update documentation.

This could explain your behavior that ECAD app worked with 1.2 and stopped in 1.5. I checked What new sections, but didn't find any reference to it.

You should probably contact ECAD app authors.

 

I also opened PTC Suport Case and Tilo Helmig from PTC explained that "in 1.5 the action was changed from PTC.CheckIn to PTC.ProdMgmt.CheckIn".

Documentation will be updated, but it looks that ECAD app will have to be updated, too.

@TomazJeras , is this at all worrying to you?  We are supposed to be going to these API structures so that we are less dependent on version matrices when trying to get two tools to connect to each other.  If simple actions like C/I and C/O are being adjusted like this, what else is going to change without warning and break our process?  I know that this is why we test and validate (which is good that I'm finding this on my development servers and not production), but it can majorly hold up any roll-out of improvements to other portions of our business if every CPS has be be vetted this much due to an API that is supposed to drive consistency...  <I'll get off my soapbox now>

Yes, I agree, this makes me worry.

We strongly suggest all customers to use REST API for external access to WNC instead of other methods like direct database modifications etc., because REST should be stable and persistent solution.

This case, unfortunately, proves exact opposite. Important change made without any documentation or notification.

Really bad practice.

Top Tags