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

Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X

OData structural properties configuration bug

ChrisB
5-Regular Member

OData structural properties configuration bug

Hello,

 

Windchill version:

Release: 11.1 M020-CPS22
windchill 2.2.2 REST Services

 

There seems t.b. a bug that makes properties in OData non-filterable when adding a separate configuration for them. Below are the steps to reproduce this issue:

 

1. We added a random string property to the `Parts` type called `RESTTEST`

   (The property is filterable)

2. We added a custom parts extension configuration as described on p.84 of the Windchill REST

     Services  2.5 User’s Guide having the following content:

Path:

[ROOT]\Windchill_11.1\Windchill\codebase\rest\custom\domain\ProdMgmt\v5\entity\PartsExt.json

 

Content of config file:

 

 

{
    "extends": "Part",
    "attributes":
    [
        {
            "name": "RESTTEST",
            "internalName": "RESTTEST",
            "type": "String",
            "readOnly": false,
            "nonFilterable": false
        }
    ]
}

 

 

As can be seen above, both `readOnly` and `nonFilterable` are set to `false`.

 

3. After having done this, the property becomes non-filterable, despite the configuration stating otherwise. This can be seen when querying the $metadata of the ProdMgmt domain:

 

 

<Annotation Term="Org.OData.Capabilities.V1.FilterRestrictions">
    <Record>
        <PropertyValue Property="NonFilterableProperties">
            <Collection>
                <PropertyPath>VersionID</PropertyPath>
                <PropertyPath>ChangeStatus</PropertyPath>
                <PropertyPath>ShareStatus</PropertyPath>
                <PropertyPath>CheckoutState</PropertyPath>
                <PropertyPath>View</PropertyPath>
                ....
                ..
                .
                <PropertyPath>RESTTEST</PropertyPath>
                ....
                ..
                .
                <PropertyPath>CLASSBINDING</PropertyPath>
            </Collection>
        </PropertyValue>
    </Record>
</Annotation>

 

 

This seems to be a bug which we haven't found a workaround for, unfortunately. However, we need to add such a mapping for a different porperty to make them writable via the API (since they are attributes stemming from the PartMaster).

 

Is there a fix for this or some sort of configuration that can circumvent the problem?

 

Because right now we have the option for attributes from the PartMaster to be

- either searchable

- or writable

 

but not both.

 

This is quite a serious issue for us so for ONCE I am asking some PTC folk for an answer, since hardly anyone seems to be able to answer any questions regarding the OData interfaces.

 

Cheers & thanks a lot in advance

Chris

 

PS: Why is there no "OData" label for Posts??

2 REPLIES 2
HelesicPetr
22-Sapphire I
(To:ChrisB)

Hi, 

what about to separate the domain. One for filtering one for writing ? 

So you would have just one config for one domain. 

PetrH

ChrisB
5-Regular Member
(To:HelesicPetr)

Hello Petr,

 

Thank you for taking the time to answer.

While this might be a possibility, the company I work for currently discourages any further customization of the OData configuration. Furthermore, this could have a negative impact on or existing software that uses the OData API.

Anyway, this doesn't change the fact that adding a property to `PartsExt.json` creates an entry in the `NonFilterable` properties. This smells kind of buggy to me.

 

Cheers,

Chris

Announcements


Top Tags