Defining a New Effectivity Scope
In a previous blog post, we demystified the recently released Effectivity Services. That post provides an overview of how to assign Effectivity criteria and how to then use that criteria to resolve your 150% BOMs. An out-of-the-box (OOTB) Aras Innovator database comes with a standard Effectivity Scope with a few simple variables, but as usual, it's also possible to define your own Effectivity Scope to fit your needs. In this blog post, we'll cover how to create your own custom Effectivity Scope by walking through the use case of wanting to resolve our 150% BOMs based on manufacturing information. Defining the Effectivity Variables Before we create the scope, we first need to figure our what sorts of information should be contained in our manufacturing scope. For simplicity, we'll keep this to a manufacturing date, a batch number, and a manufacturing location. Let's start by opening up the Effectivity Variables and checking the existing variables. Log in as admin Navigate to TOC > Administration > Effectivity Services > Effectivity Variables Run an empty search to see all the existing variables Manufacturing Date We want our scope to be able to resolve based on when a particular batch of parts was manufactured. By following the steps above, we should see that there's already an existing Date variable. This seems generic enough that we can re-use it for our manufacturing date. Unfortunately, there don't seem to be existing variables for our other two pieces of information, so we'll have to create new two new Effectivity Variables. Batch Number We also want our scope to be able to resolve on a specific batch number, so that in the event that we have a faulty batch, we can check what the BOM looked like at the time those parts were created. Create a new Effectivity Variable Name - Batch Type - String Save and close this Effectivity Variable Manufacturing Location Lastly, we want our scope to be able to resolve on the location where our parts are manufactured. There's actually an ItemType that comes with the Manufacturing Process Planning (MPP) application that represents exactly this piece of information, so we can point our new Effectivity Variable to that ItemType to save the work of creating one ourselves. Create a new Effectivity Variable Name - Location Type - Item ItemType - mpp_Location Save and close this Effectivity Variable There's one extra step we'll need to do for this variable. Because this points to an ItemType, we need to configure Effectivity Services to be able to resolve based on this ItemType. We can do this by following the steps below. Navigate to TOC > Administration > ItemTypes Search for and open the ScopeCacheDependency ItemType Select the Poly Sources relationship tab Add a new relationship to the mpp_Location ItemType Save the close this ItemType Creating the Effectivity Scope Now that we have all of our Effectivity Variables, we can create the new Scope that uses them. Navigate to TOC > Administration > Effectivity Services > Effectivity Scope Create a new Effectivity Scope Name - Part BOM Manufacturing Scope Builder Method - effs_scopeObjectBuilderMethod This is a standard method that exists in the database In the Effectivity Scope ItemType relationship tab, add a new relationship to Part BOM In the Effectivity Variables tab, add a relationship to the Date, Batch, and Location variables Save and close this Scope We're finished! Effectivity only needs to be configured on a per ItemType basis and not on a per scope basis. Because the BOM Structure relationship tab on Part is configured to work with Effectivity OOTB, we don't need to do any additional configuration to add support for our new Scope. We can just hop right into using it. Using the New Scope Because we've already covered how to author and resolve on effectivity in our previous blog post, we'll instead focus this section on pointing out how our now two existing Effectivity Scopes will interact. To begin, we'll open up a Part BOM that has a few relationships and, more importantly, has some effectivity already defined under the default Aras Part BOM Scope. As a quick refresher, we can right-click and anywhere in the grid and select View Effectivity to open up a panel on the right of the grid. This panel shows us more details about the effectivity of a selected row and also lets us quickly and easily edit the effectivity of the selected BOM. Authoring Effectivity for Two Scopes on One BOM If we take a look at the Effectivity editor, we'll see that there's an existing row describing an effectivity condition for the Aras Part BOM Scope. We can easily add a new row here to define another condition under our new scope. Click on the button to add a new row In the Effectivity Scope field, enter Part BOM Manufacturing Scope In the Effectivity Expression field, enter some expression such as Batch = 123 AND Date = [10/8/2020] AND Location = Detroit Click Apply to save this condition We'll see that in the Effectivity Pane, a new row was added with our provided effectivity criteria. Additionally, we can see that there is now a comma separated list in the main grid showing all of our effectivity criteria together. As a note here, it's also possible and sometimes encouraged to add multiple rows of effectivity criteria for the same scope. In our example, perhaps this same part is used in multiple different batches that were created on multiple different dates in multiple locations. We could write this using only one very long expression but that added complexity could quickly make it hard to maintain. Instead, we could just add a new row for each batch. Click on the button to add a new row In the Effectivity Scope field, enter Part BOM Manufacturing Scope In the Effectivity Expression field, enter some expression such as Batch = 234 AND Date = [10/15/2020] AND Location = Detroit When we choose to filter the results, this BOM will be returned if either of these expressions match our criteria. For example, if we choose the filters below, the item will still be returned when the BOM is resolved because it matches our first effectivity condition. One thing to keep in mind is that each expression on the item is treated as an individual entity even if they both belong to the same scope. For example, we can select the filters below where the Batch matches one of the expressions and the Date matches another, but the combination of Batch and Date does not match any of the expressions. If we apply this criteria, we will see that the BOM is not returned when the structure is resolved. Two Effec Scopes with the Same Variable At the beginning of this design process, we decided to re-use the Date variable from the default Aras Part BOM Scope for our custom scope. In practice, this effectively functions as if there were two different Dates. Let's look at a BOM that has two different expressions: one for each Scope. Now if we try to resolve this structure under our Part Manufacturing Scope with the date 10/1/2020, we'll notice that the BOM is not returned when the structure is resolved. While this BOM does have an expression referencing 10/1/2020, it is only valid under the Aras Part BOM Scope. Similarly, if we try to resolve this structure under the Aras Part BOM Scope with a date of 10/8/2020, the BOM will also not be returned. Conclusion Each part of Effectivity Services is fully customizable. Adding new Effectivity Variables or entire new Scopes is quick and simple with the most time consuming part being the actual data entry itself. As we continue to explore Effectivity Services, future blog posts will cover topics like adding effectivity to a brand new ItemType like Part Document. Each business has it's own unique challenges, so go out and try adding a new Effectivity Scope to solve yours.Do's and Don'ts of Designing Applications in Aras Innovator
Customization is a core part of the Aras Innovator platform because we know that the unique problems of your business cannot be solved by a one-size-fits-all PLM system. If you've followed along with our Aras Fundamentals series, you've seen that almost every piece of the data model can be configured and extended to fit your use cases. This can be both a blessing and a curse. This blog post will cover some common design principles that are not unique to Aras and explore how you can apply them to your Innovator instance. These principles are best considered from the very start of the design process, but they can also be a helpful guide if you're looking to refactor an existing Innovator instance as well. Following good design patterns can have a number of benefits from improved performance to easier maintenance to happier users. Do Keep It Stupid Simple (KISS) This principle argues that systems work best when they are kept simple and avoid unnecessary complexity. When given the freedom to fully customize a data model, it can be easy for things to grow beyond their original scope very quickly. The Aras platform respects its users with the power that it gives them, but it also asks for the same respect in return. We can apply this concept to a number of places in our Innovator instance. Don't Use "Boss" ItemTypes One common design problem I've seen is when one ItemType is responsible for a ton of different things. These are ItemTypes that have hundreds of custom properties and Workflows that seem to branch on forever. This can be a nightmare for users since even just trying to run a search means sifting through hundreds of columns most of which are off screen at any given time. This can also be a pain for administrators who are trying to add functionality or just perform routine maintenance. Instead, it's better to try to limit ItemTypes to a singular purpose. If you notice one ItemType getting too large, consider if it would make sense to split some of the properties or responsibilities into a new ItemType entirely. As an example, let's consider a situation where we want to track where our Parts are being manufactured. We could add properties like city, state, and country onto our Part ItemType. What happens when we want to shift production of a Part to a new location or indicate that a Part can be made at multiple locations? At this point, it might make more sense to create a whole new Plant ItemType and link the Part directly to a Plant instead. Don't Use Overly Complex Maps It is just as easy for Workflow Maps or Life Cycle Maps to also suffer from the same problem of having too much complexity. Similar to ItemTypes, Workflows with hundreds of activities will be a burden on both users and administrators. If you notice a very large Workflow, consider options like adding a subflow or even having two different Workflows that are assigned to an item based on some criteria. Don't Repeat Yourself (DRY) This software design principle argues that redundancy should be avoided wherever possible. If a snippet of code is used in five different locations, it should instead be abstracted into a function so that when changes need to be made, they only need to be made to a single location. We can apply this same logic to our Innovator instances as well. Do Use ItemTypes for Common Data Good design tends to solve multiple problems at once. Let's go back to our previous example of storing information about where our Parts are being manufactured. It might also be beneficial to track this information in our Change Management process, so we know which Plant made the change request. If we were still using properties for city, state, and country to track this information, we would need to add each of these three properties to all of our Change Management documents and also populate each of these properties when a new one was started. Instead, we've already wrapped all of that information into a Plant ItemType, so we only need to add one property to each of our Change Management documents. As an added benefit, if we want to track more information about the Plant, we only have to add a property to the Plant ItemType instead of to each and every Change Management ItemType. If you have the same pieces of information stored across several ItemTypes, it might benefit you to extract those out into a single new ItemType which makes adding new functionality easier. Do Use Poly Items As another example, we can take a closer look at the Change Management documents in a standard Innovator database to see this principle in work. A Problem Report (PR) can be created to report a problem with a Part, a Document, or a CAD Document, and stores this item inside of an Item property. Since Item properties can only link to a single ItemType, the straightforward approach would be to create three different properties: affected_part, affected_document, and affected_cad. While we might be able to make this work, what happens when we want to allow PRs to be created for a new ItemType or for five new ItemTypes? Adding a new property for each new ItemType is cumbersome and bloats the PR ItemType with a bunch of additional properties that will not be used most of the time. Instead, an approach that avoids this kind of repetition is to use a single Poly ItemType, and in fact, the PR in a standard database has a single affected_item property that points to the Change Controlled Item Poly ItemType. If we want to configure PRs to support one or more new ItemTypes, we would just need to add them as Poly Sources of the Change Controlled Item ItemType. You can check out our blog post on Poly ItemTypes for some more information. Don't Reinvent The Wheel (The industry is still working on turning this one into a nice acronym.) This principle argues that you should not spend time or resources writing functionality that already exists. This has the benefit of keeping the system small and allowing more development time for other problems. There is a number of common use cases that can be achieved on the Aras Innovator platform through configuration alone with no additional code. Do Data Validation One common use case is to ensure that the data users enter follows a specific format. Depending on the exact use case, this can achieved a few different ways. Filter Lists can be used to limit the selections of a dropdown to a subset based on some other value on the Item. If you're comfortable with it, you can also use a Regular Expression to match a property value with a pattern before it can be saved. Do Use Notifications Aras Innovator also supports a number of built-in options for notifying users of work or changes to the system. EMail notifications can be configured as part of a Workflow or Life Cycle so that when a specific activity or state is reached, a user is emailed. In-app notifications can also be configured using the Message ItemType. These kinds of notifications are most commonly used to report system downtime for maintenance. Do Restrict Access There are a number of options to configure access control within Aras Innvoator. For more information on this, check out our blogs on the standard permission model and our extended forms of access control. Conclusion While this blog post can help provide a strong foundation for new administrators, these design principles are not unique to Aras. The web is full of resources on how to design systems and code bases, and we encourage you to continue your design adventure past this blog post. If you have other design principles you follow for your Innovator instance, please share them in the comments below.Customizing Item Menus with CUI
In previous blog posts, we've covered how to add custom menu items like buttons and shortcuts using the Configurable User Interface (CUI) data model introduced in 11.0 SP7. Using this same data model, it's also possible to add menu items that are specific to individual ItemTypes that you want to have special functionality.
