Be honest—are your users sick of playing PLM games with you? Perhaps this will help. It’s Santa’s PLM Naughty or Nice List, and of course, he checked it twice. Rest assured it’s been validated.
- Open and published APIs?
If you think using multiple closed technology stacks in your PLM is going to get you on the “nice” list, you’re mistaken. The big man considers this to be extremely naughty. Unsuspecting boys and girls customizing on these technology stacks isn’t sustainable, causing them to get locked-in. Not the kind of Christmas experience anyone wants. And if you haven’t customized on one these so-called PLM suites, don’t. “You’ll shoot your eye out, kid” (A Christmas Story).
- Time to deploy?
Santa defies the space-time continuum. He deploys in a single night, at super luminal speeds, with nothing but a high tech sleigh and nine reindeer—one with an unusual variant in terms of nasal luminescence. If you’re on your fourth quarter of deployment and all you have are four French hens, you’re on the wrong list.
- You upgrade every year or two?
Your PLM system is not like a fruitcake that can last for 5, 10, or 15 years without upgrading. If it is, than ask Santa for a new one that will be upgraded by the vendor.
- Does your PLM facilitate secure collaboration with your partners, suppliers, and customers?
Remember, Santa works globally with tens of thousands of mall Santas, elves, toy OEMs, suppliers, good little boys and girls all over the world, and a few hundred CIOs that still believe, so the expectation is for secure global collaboration. Aras has worked with the North Pole on extended security to allow partners, suppliers, and customers access within a replicated firewall—and just the gifts they have the right to open.
- How secure is your intellectual property?
Do you think it’s enough to leave little Cindy Lou in charge of your data security and just forget about it? Wrong-o! Let me tell you about these users in Whoville who were breached by a hairy, pot-bellied, pear-shaped, 53 year-old snub-nosed hacker with a cat-like face and avocado complexion. Their data was not properly secured. Your PLM should be able to protect down to the object level so we don’t have ITAR parts ending up under the Christmas tree. Sadly, in their case, nothing was left in Whoville but the smallest of bread crumbs (The Grinch). Your data must be secured. To do this, you’ll need the strength of “ten Grinches plus two,” and a heart that can scale three times its size.
- Do you have a seamless Digital Thread?
So, your PLM got hit by a reindeer walking home on Christmas Eve. You bought it—you deserve the hoof prints.
- Do you have operational Digital Twins?
How do you think Santa controls all his mall Santas? Maybe that’s not the best use-case. For those of you who deserve a lump of coal, yet want something better, here’s a free Aras Innovator downloadable. If you want to experience nice PLM users and an open, flexible, scalable, and upgradable PLM, check out ACE 2019 in Phoenix, AZ. Anywho, I think you get the point. Remember, he knows if your PLM is bad or good, so be good for goodness sake. In the end, try to lavish your users with an open, flexible, scalable, upgradable, secure, and easy-to-use PLM based on a digital product platform. Treat your data and people with kindness, warmth and generosity this season, and give them a real Digital Thread. www.a
In a previous blog post, we gave an introduction to AML and covered the basic structure of an AML request. While the simple concepts covered in that post are powerful enough for many use cases, you can make your AML requests even more useful with just a few simple tweaks by adding attributes to your requests.
Basic Item Attributes
There are a handful of attributes that are available for every type of AML request.
Name | Usage | Example |
type | The name of the ItemType to query on. Almost every query will need a type to run properly. | <Item type="Part"> |
where | An optional condition to filter the results of your query | <Item type="Part" where="[Part].item_number like 'MP%'"> |
id | The unique ID of the specific item to query on. Using this attribute is equivalent to using a where clause like where="[Part].id = 'YOUR_ID'" | <Item type="Part" id="1FEB0204D83147CCA9DA1CB658F9642D"> |
action | The type of query you want to perform. (e.g. "get", "update", "add", etc.) | <Item type="Part" action="get"> |
doGetItem |
A boolean value indicating whether any items should be returned from the query. Useful to speed up execution of actions like "update" and "add". Is true by default. |
<Item type="Part" action="update" doGetItem="0"> |
Specific Item Actions
The attributes above are available regardless of what kind of AML query you are performing. However, most of the standard queries you can perform through AML also have more specific attributes available.
Get Actions
The get action has a number of different attributes to control what items get returned and how. For a full list of what attributes are available for each different standard action, you can check out section 2.4 of the Aras Innovator Programmer's Guide.
Name | Usage | Example |
select | Specify which properties will be returned by this query. | <Item type="Part" action="get" select="item_number,name"> |
levels | Returns all relationships to the level defined. Using levels="2" will return all relationships as well as all relationships of those child items. Should be used sparingly due to performance issues. | <Item type="Part" action="get" levels="2"> |
serverEvents | Determines whether the server events on the ItemType will be run as part of this query. Can be useful when debugging new onBeforeGet/onAfterGet server events. By default the server events will always run. | <Item type="Part" action="get" serverEvents="0"> |
Edit/Update Actions
Name | Usage | Example |
version | Only applicable to Versionable items. Determines whether the item will be versioned as part of this update. Can be useful when performing a one-time mass edit as a result of a data model change. | <Item type="Part" action="edit" version="0"> |
serverEvents | Determines whether the server events on the ItemType will be run as part of this query. Can be useful when performing an initial data load to both improve performance and avoid potential conflicts as a result of the server events. By default the server events will always run. | <Item type="Part" action="update" serverEvents="0"> |
Custom Actions
In addition to all of the standard actions, you can also use the action attribute to pass in the name of any Method in your database. Running a query like this will use the Item you've built in the AML query as the context item when you run your Method.
As an example, we'll create a new action with the Method code below. The purpose of this new action is to allow us to add a new Part with an optional property that will let us attach it to an existing part in the database.
gist.github.com/…/c112e17a5c1e4f6201a8f7ff746b6125
With this new action in place, the AML we run will end up looking like the example below.
<AML>
<Item type="Part" action="Add Part and Attach to Parent" parent="MP0101">
<item_number>P-0001</item_number>
<name>New Child Part</name>
<description>A part created as an example to show off custom actions</description>
</Item>
</AML>
May you and your family have a wonderful holiday season!