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

ThingWorx Navigate is now Windchill Navigate Learn More

Translate the entire conversation x

Incorrect Job Order Opened Instead of Requested One + Description Field Cleared

CB_10149096
12-Amethyst

Incorrect Job Order Opened Instead of Requested One + Description Field Cleared

Hello. We created a job order with ID 343 in the RTPPM System. However, when we tried to open this job order, the job order with ID E53435P001T001 was opened instead. Apart from containing the number 343 in it, there is no similarity between them. In fact, the job order with ID E53435P001T001 is not even assigned to the machine that was opened.

At first, we thought this was due to editing the job order creation mashup, but we realized that the same issue occurs even when we create the job order using the StartJobOrder_JOR service inside the machine’s thing.

Also, sometimes job orders that have no such similarity with each other are opened in place of one another.

Another issue is that the description field of the opened job order becomes empty. The synchronization on the machine’s thing is turned off.

ACCEPTED SOLUTION

Accepted Solutions

Hi  again.

 

We create the job orders using a custom service we developed ourselves, and they are started from the Operator Dashboard. The job orders created by our service vary depending on the data coming from the machine things.

 

By the way, we were using Thingworx 9.3 before, and after upgrading to 9.5, the issue with  incorrect job orders being opened has been resolved. However, as far as I understand, job order IDs cannot contain each other — for example, if there is a job order with ID 9 and another one with ID 99, it causes confusion.

Best regards,

View solution in original post

6 REPLIES 6

I don't see a request or question in this posting, not sure what it is aimed at.

Also this should be a ticket with PTC support, so they can look into the system with you and see if it is a product issue.

Hi CB

 

A big suspect is the ID column versus the UID column. To be clear, the Id column in the Joborder table is its name, and the Uid is a number that is unique. Please make sure that when calling StartJobOrder_JOR, you use the names (or Id) for the name parameters, and the uids (numbers) for the uid parameters.

 

For the description being emptied, I want to validate : is it the Description column in the Joborder table? To my knowledge this is not used by RTPPM, instead it uses the following (and I'm not sure if all of them are required) : 

- Joborder.Id

- Joborder_ap.Name

- Joborder_ap.Displayname

 

In case we need to debug this further, I want to leave a note : the Description is a setting in the JobOrderModelPropertyBindings table in the Configuration tab in Composer. But I expect that it should only look at this at creation time.

Hi  mstarnaud

We are aware of the difference between Id and UID and we are careful to use them correctly when starting. The reason we shared this here is that we feel a bit constrained with the situation.

Regarding JobOrderModelPropertyBindings, it is not only used at the time of job order creation, but also when updating existing job orders. We even experienced the same issue when the Sync Job Order box was unchecked. Previously, we had bound a property to the JobOrderModelPropertyBindings section, thinking that it would take the existing value, rewrite it, and allow us to bypass this situation. Later on, we removed the property. Still, even with sync unchecked and the property field empty, we can confirm that the description in an existing job order is being cleared.

So, perhaps Rokko is right — opening a ticket might be the most appropriate way forward.

Best regards,

Hi CB

 

Sorry for the delay, I am dealing with multiple urgent items at the moment. It will take some more days before I have time to really investigate this.

 

For the bindings, as far I know they should only be used at joborder creation (if you create them with the tags). If they're used at other times, I don't think that should happen and I need to investigate and possibly raise this as a bug.

 

I do have to ask : how do you use your joborders? Do you initially create them using an import tool, such as the Endpoint? Or do you use the tags? Also, you specified that you use the StartJobOrder_JOR service to activate them, so how does this service get called? Do you use a custom tool that calls this service? Or is it part of a standard process, like the Start button in the Operator Dashboard or a tag getting a value? It will be easier for me to debug this if I know what processes you're using to get the issues.

 

Speaking of that, opening a ticket for possible bugs is usually a good idea. But a problem you can encounter is custom tools would not be supported in support tickets, so you may have some limitations there.

Hi  again.

 

We create the job orders using a custom service we developed ourselves, and they are started from the Operator Dashboard. The job orders created by our service vary depending on the data coming from the machine things.

 

By the way, we were using Thingworx 9.3 before, and after upgrading to 9.5, the issue with  incorrect job orders being opened has been resolved. However, as far as I understand, job order IDs cannot contain each other — for example, if there is a job order with ID 9 and another one with ID 99, it causes confusion.

Best regards,

Well that's great news that it's solved. But I have a few questions to help in case someone gets the same issue in the future.

 

- For the "description field of the opened job order becomes empty" part of the issue. Was this solved, and if yes, how did you solve it?

 

- For the wrong joborder getting started, how did you solve it? Is it related the the "IDs cannot contain each other" issue, meaning it was only failing when the new joborder's name was related to the name of another? Or was the issue something else?

 

When I have time I will try to reproduce the issue about the IDs containing each other, and if necessary raise it as a bug to be fixed.

Announcements


Top Tags