PLM 360 General Discussion

PLM 360 General Discussion

Reply
Active Contributor
ForrestJudd
Posts: 37
Registered: ‎04-28-2008
Message 1 of 3 (156 Views)

Idea for accessing filtered pick list items

156 Views, 2 Replies
10-26-2012 04:26 PM

TLDR version of my question:  I have a complicated way of accessing items from choices in filtered picklists.  Is there an easier way?  If not, can I count on the functionality used by this method being available for the foreseeable future?

 

There's a fundamental limitation to filtered picklists:  we can't get at a particular record that might be defined by the combination of selected properties, because there's no guarantee that said combination will yield a unique record.  This makes sense to me.

 

However, what if we know we're configuring things in such a way that we can derive a unique record from the combination of selections?  If we had a way to query a workspace to return a record with those properties, we'd have access to it and all of its other properties.

 

I don't see anything in the scripting reference that would let me run a query like that.  I could try a brute force approach and just test every record in the system for a match, but that fails even for the smallest data set; the script timeout kills that approach.  However, what if we had a list of IDs of all the records we were interested in?  That would give us a much smaller list of records to check against.  I've tested that and so far it's been successful.  Here's the code:

 

 

 

var customerList = loadItem(634);
var customerIDs = customerList.LISTINFO.split("|");

for (i=0; i <customerIDs.length; i++)
{
    try
    {
       var catItem = loadItem(customerIDs[i]);
       
       if (catItem.CATEGORY === item.ITEM_CATEGORY)
       {
           if (catItem.SUB_CATEGORY === item.SUB_CATEGORY)
           {
                if (catItem.SUB_SUB_CATEGORY === item.SUB_SUB_CATEGORY)
                {
                    item.STRINGTEST = catItem.CATEGORY_CODE;
                    break;
                }    
           }
       }
    }
    catch (err)
    {
        
    }

 

In the above example, the record with ID 634 is a very simple record with just a name, a description, and a pipe delimited list of other record IDs:

 

lists.png 

 

 

The code splits the ListInfo field into an array of IDs for all records of the type we're interested in.  We just look at all those records to find the one we want, then act on it when we find it.  

 

In conjunction with this I'd like to add scripting to workspaces for which we're maintaining lists so that these List records are updated with new IDs for newly added records.  Otherwise these lists would need to be maintained manually, and that could cause problems unless record addition is tightly controlled.

 

There are some serious limitations with this approach as well.  I think the longest field we can assign to a record is a paragraph, with a limit of 4000 characters.  If every ID is 4 digits, that yields a maximum number of records for a given list to 800.  IDs will reach 5 digits pretty quickly in a production system once various records of existing data are imported.  That leads to only 667 records for a given list.  This could be worked around by using multiple list records, though.

 

Another limitation is that eventually we'll have so many records to check against that we'll hit the script timeout again.  From that point forward, unless some records can be purged from the list, the functionality breaks.  This would probably happen after weeks or months of normal use, causing an abrupt change in workflow.  This also would make the approach fundamentally incompatible for certain record types, like Items, where we could have many thousands even from the outset of a new system.

 

Finally, this takes advantage of the loadItem function, which is listed as deprecated in the scripting reference.  If that functionality disappears, this idea breaks as well.

 

So, my questions:

 

  • Am I missing a simpler way to accomplish the basic goal, which is to access a record based on knowing some of its property information?  
  • If not, is there a plan in the future to provide this functionality via scripting?  I'd like to know if we can expect a more long-term method of this basic approach to be available in the future before going down this road, only to abandon it when it reaches its inevitable limitation.

 

Active Contributor
ForrestJudd
Posts: 37
Registered: ‎04-28-2008
Message 2 of 3 (140 Views)

Re: Idea for accessing filtered pick list items

10-29-2012 09:53 AM in reply to: ForrestJudd

Regarding this bit:

 



In conjunction with this I'd like to add scripting to workspaces for which we're maintaining lists so that these List records are updated with new IDs for newly added records.  Otherwise these lists would need to be maintained manually, and that could cause problems unless record addition is tightly controlled.

 


I figured out this morning that I can get at an item's dmsID by using the following property:

item.descriptor.dmsID

 

So I should be able to automate the addition of newly created items to my list records. 

 

My biggest concern now, aside from the inherent limitations, is if accessing items via their ID (via loadItem) is going to disappear before some equivalent functionality is provided.

Product Support
piggeej
Posts: 281
Registered: ‎03-27-2012
Message 3 of 3 (126 Views)

Re: Idea for accessing filtered pick list items

10-30-2012 08:37 AM in reply to: ForrestJudd

Forrest,

 

Nice solution for the issue you have found.

 

First off, No the dmsID is not going away.

Second, I love the idea and the functionality you are looking for; I would highly suggest adding this to the idea exchange so the developers can see this also.



Joe Piggee
Support Specialist
Product Support
Autodesk, Inc.

Announcements
Are you familiar with the Autodesk Expert Elites? The Expert Elite program is made up of customers that help other customers by sharing knowledge and exemplifying an engaging style of collaboration. To learn more, please visit our Expert Elite website.