Simple AML queries can be broken down into three parts: the ItemType that you want to affect, the action that you will use, and the properties that will feed into that action. However, there is no requirement that the properties you specify for your AML query correspond to a property on the ItemType. In this blog post, we'll cover an example of how you can use this feature of AML to your benefit.
Breaking Down AML
Let's start by exploring how the server responds to a property in an AML query that doesn't exist on the affected ItemType. We'll refer to this kind of property as a fake property. We will first execute a normal query that adds a part by using the AML below.
The result is that a new Part called PRT-0001 gets created as expected. Now let's add a fake property and see what the server returns. If you have a simple development environment set up, try running the AML below.
You'll notice that the AML is successfully applied and that the fake_property is simply ignored in the resulting Part. Below, we'll explore an interesting use case that can be solved by using one of these fake properties.
Utilizing Fake Properties
The Use Case
When a user creates a Document, we want to create one additional Document that is visible to a different group of users. For simplicity, the sample code provided will focus only on the creation of the additional Document.
Initial Attempt
This use case seems fairly straightforward on the surface. Let's try to accomplish this with a simple onBeforeAdd Server Event that we'll attach to the Document ItemType.
When we try to create a Document now, we'll notice that the save never completes and our instance of Innovator will hang indefinitely. The issue we're running into is that the Document we're creating is also triggering it's own onBeforeAdd event which is in turn creating a new Document that triggers another onBeforeAdd. This loop will repeat until we forcibly close Innovator.
The Solution
One way we can work around this is by taking advantage of a fake property. When we create our new Document, we'll set a new property on it called is_sibling. We'll then check to see if this property is set in our onBeforeAdd event. If that fake property exists, we'll know that we shouldn't create another sibling in order to avoid the infinite loop we encountered with our first attempt.
When we create a Document with the updated Server Event, we'll notice that the save completes successfully and that a sibling Document is also created.
Fake properties are a particularly useful tool to keep in mind when working with different kinds of Server Events. They allow that extra bit of communication that allow Server Events to be flexible to all of your use cases.
LOOKING FOR MORE ARAS INSPIRATION?
Subscribe to our blog and follow @ArasLabs on Twitter for more helpful content! You can also find our latest open-source projects and sample code on the Aras Labs GitHub page.