If you missed last month’s Agile PLM featured webinar on our Automation Engine (get to know), read on regarding some frequently asked questions from our attendees and relevant answers provided by Xavor’s Tom Nelson, Principal Product Management and Innovation regarding this robust solution.
Does this tool replace the need for Groovy or PX’s?
It’s close. If you are doing relatively smaller items that you would typically do through the event handlers, it’s replaced the need for Groovy by about 80-90%. There are still some things that you can do in Groovy that we haven’t put into the system.
For example, Groovy can go out to a network directory and pull files or do extra things. We will have that in upcoming releases of the solution. We can also have the Automation Engine call Process Extensions. You may have Process Extensions that do a lot of stuff like web interfaces and things. This tool won’t do those kinds of things.
It’s not a replacement for a full-blown Process Extension. Definitely, for most things that can you do in Groovy, you can do with this tool.
Do these events also appear under the Java Client Event management module?
Yes. It actually takes whatever you’ve created in the Automation Engine and puts it right into the Java Client. It’s just like you’ve created it from scratch through Agile, but you are using the Automation Engine to get it in there.
Can this tool be used to filter “Save As” fields allowing the create user to only copy selected fields and content?
Yes. It’s actually just the opposite of putting default values in. We don’t allow them/users to put in certain values. This can be a little tricky because now you’re working up against roles and privileges in Agile.
So if they’ve got the privilege to enter data into a particular attribute but your event is triggered saying that they don’t get to enter data – that works well. It’s when they go the other way, when they don’t have the privilege to modify an attribute and your event has told them that you want to put a value in there, you run into a conflict.
Then we basically throw a warning explaining what the issue is.
What does the Warning look like in the Agile Web UI?
It places a warning on the page. If you look right below the tabs of an object for instance, the warning comes up or as an error message in its own little message window right there.
What are the prerequisites for this software – Agile and Java version?
The prerequisite is that you are a licensed user of Agile PLM. Install it on the Agile server, make sure all of the pointers are set-up and then set-up the security. Next, you are off and running. It’s a very straightforward deployment of the tool.
Should I expect any system performance problems?
No. It will literally be the same as if you are using Groovy Scripts. It’s not going to add any additional load that you would see past a Groovy Script. Typically your Groovy Scripts are going to be smaller than large Process Extensions. Some of the PX’s that we work with can be thousands of lines long and do a hundred different things. Typically you hit a key, it does something quickly, comes back and the user is off and doing the next thing. We don’t expect you to detect or measure a hit in performance.
How long should I expect it to take to get proficient with this application?
As long as you are fairly familiar with Agile PLM and Agile Events, the training for this is around 60-120 minutes. Then it’s just like anything else, you will want to take time to go and experiment with it. You should be able to successfully create your own scripts after completing the basic training.
What’s your product strategy to keep up with Oracle’s Agile Product roadmap? Is there a timeline SLA for your product matching Oracle’s releases?
We have an entire team at Xavor dedicated to Agile PLM and we will be keeping up with Oracle’s Agile PLM releases. With a whole series of Agile PLM solutions, about 2500+ Process Extensions, we are continuing to develop more. We aren’t dropping any support of the Agile PLM product.
With Automation Engine, it’s going to follow a very similar format as to what Oracle does now. If bugs get reported that we didn’t catch during QA, we will go in and address those. When it makes sense to do a new release, we will do a hotfix, etc. depending on the criticality of the problem. For this solution, we do a new release every 6 months to a year.
When Oracle releases a new version of Agile, we have a process that we follow to complete an upgrade in our own environment. We make sure that it works by testing the upgrade process. Then we take all of our solutions and test every one of them with all of the scripts that we’ve used in the past. Usually within a week or two of the new release of Agile, all of our products have been tested. If we find that we need to make any changes to a solution, we make them right then and there.
Most of our solutions run with the Agile SDK and that actually gets changed or modified every time Oracle does a new release of Agile. Very seldom do we find that we have to change any code on our Process Extensions. We keep aligned with Oracle’s new releases as closely and tightly as possible.
When working in a multi-system environment where you are doing development in one system, validation in another, and running your Production in yet another, how do you propagate these configurations from one system to the next?
There’s actually a couple of ways to do it:
- The tool essentially creates an XML file and then pushes that data into Agile itself. We have a way to grab just the XML file and move it to another system. You basically import it into the Automation Engine and simply click a button where it says to “push it into the Agile Java environment.”
- On the other way to do it is to not worry about getting to that level. Go into the Agile Java environment and export your subscribers. What this does is creates another XML file which you can take to the next system and do an import of that XML file.
Do we need to create events twice? One in one tool and one in Agile?
No. You can create the event in the Automation Engine and push it into Agile and then just use it as if you’ve created it within Agile. You can also create an Event in Agile that calls for an Event that you’ve created in the Automation Tool.
You’ve really got a lot of flexibility. You can create events in both tools and link them together or just use one tool or the other. The great thing is that if you use the Automation Engine, as you create these things (i.e. events, actions, etc.), it pushes them over into the event library within the Java Client of Agile.
It makes it look like you just created it there. We’ve given you a lot more flexibility of what you can do.
Can this tool be used as an “Auto Description Generator” for more standard and consistent Item Descriptions?
Yes. We’ve actually helped customers using this tool to do this. You can set-up the Auto Description Generator based on 5, 10, or 15 other attributes and given the ability where you can to do some of the basic math, you can look at the attributes and use those to fill in the Auto Description.
It’s not only Auto Description but Auto Revision for a change. Some customers, for instance, use numeric revisions before production release and then alpha revisions after release or vice-versa. We can look at the lifecycle of the product, proposed lifecycle and put in the next appropriate revision based on a whole set of criteria.
With Auto Descriptions it doesn’t have to just be the description but other attributes as well. You’ve got full control over pulling information out of attributes, modifying it and placing it back into another attribute.
Are conditions ANDed together or ORed together, or both?
Both — ANDed and ORed
Is it a separate set-up on who can work in this tool or would it take the access privileges from Agile for a login user?
Currently what we’ve done is set-up its own security. Right now Automation Engine has its own separate security and credentials to look into it.