Matt Paulhus's Profile
Agile Angel



Item Master, Scripting events, Agile Administration Also used 9.3.4. at Crane Aerospace & Electronics, Redmond, WA
Title Configuration Analyst
Company FujiFilm Sonosite
Agile Version 9.3.3.
  • Agile Angel Asked on September 27, 2018 in Product Collaboration.

    Try this too, as I understand how confusing it is sometimes to put the BOM table together:

    SELECT j.item_number AS parent_item, 
           i.description AS item_description, 
           f.text        AS BOM_notes, 
           date01        AS phased_in, 
           date02        AS phased_out 
    FROM b 
           LEFT OUTER JOIN agile.agile_flex f 
                        ON b.item = 
                           AND f.attid = 1036 
                           AND = f.row_id 
           JOIN agile.item i 
             ON b.component = 
           JOIN agile.item j 
             ON b.item = 
    WHERE  change_out = ‘0’ 
           AND j.item_number = :parent_item; 

    • 9 answers
    • 0 votes
  • Agile Angel Asked on September 25, 2018 in Other APIs.

    You’re right, that was knowledge I got from a stack trace created by a Groovy script.

    No idea about Java PXs, but my gut instinct is to create a java PX that simply throws an Exception and prints the stack trace.  That may tell you more about the class next level up where it’s hard coded.

    • 3 answers
    • 0 votes
  • Agile Angel Asked on September 24, 2018 in Other APIs.

    You’re asking about whether you can change the “Job submitted for running asynchronous event subscribers in the background” to something different, right?  Example, Agile instead writes “See the comment made on this ECO for the results” or “Check the Event Subscriber Monitor for the results.”.  
    I seriously doubt it as that should be hard coded in the com.agile.agileDSL.ScriptMgr.AgileDSLMgrSessionBean.invokePostAction() class instead of your EventActionResult.doAction() class.

    • 3 answers
    • 0 votes
  • Agile Angel Asked on September 19, 2018 in Product Collaboration.

    You should be able to get away with just using the CHANGE_HISTORY table here through WORKFLOW_PROCESS is ok too.  The trickiest part is defining the requirements – namely, how do you want cycle count to be affected if the ECO was returned or rejected more than once?  Do you want it just the last time it was submitted compared to the last time it was returned?  Looks at the history tab of an ECO and then use the CHANGE_HISTORY or WORKFLOW_PROCESS tables (which query off of what you see in the history tab).  

    This query, for instance, shows me every time ECO1234 was moved from Pending to Submitted and from Submitted to Pending and returned 5 rows due to the Change’s back and forth history.  From here, I’d just want to lock down exactly what I wanted to see as well as some math to subtract two local_dates for the cycle time.  

    SELECT * 
    FROM   agile.workflow_process 
    WHERE  change_id = (SELECT id 
                        FROM   agile.change 
                        WHERE  change_number = ‘ECO1234’) 
           AND ( ( state = ‘59745’ 
                   AND next_state = ‘59742’ ) 
                  OR ( state = ‘59742’ 
                       AND next_state = ‘59745’ ) ) 
    ORDER  BY local_date;

    • 4 answers
    • 0 votes
  • Agile Angel Asked on September 11, 2018 in Other APIs.

    The main alternative here that I can think of is a POST event.  Upon ECO approval, and after your other PX has already blocked any signature from being registered when there’s missing fields on the ECO, write a different PX that will conduct a few checks (such as eco.audit(), missing fields, all-approve, etc.), then change the workflow.  Turn off auto-promote and just let your PX do the heavy lifting.  You can trigger this by ‘Approve for Workflow’ or even as a scheduled event w/ Query, among other options.  

    I empathize with you too – failed auto-promote messages don’t tell a user what was missing until someone goes in and manually tries to change the status.

    • 5 answers
    • 0 votes
  • Agile Angel Asked on September 10, 2018 in Product Collaboration.

    Hi Kevin, trying seeing if Oracle Doc ID 2213158.1, Doc ID 2251189.1, or Doc ID 1271285.1 help at all.  I remember reading about how basic and advanced searches can differ and can have issues.  Try those Doc IDs for some possible hints. That’s peculiar too – do you have a screenshot of this search?

    • 6 answers
    • 0 votes
  • Agile Angel Asked on September 10, 2018 in Other APIs.

    Mmmm…I’m pretty sure you can’t mix those two in a single script.  Regardless of whether or not the ECO had the mandatory attributes filled in or not, I’m very certain Agile would have bumped the object version up since Agile will log that your script ran to the history tab of that eco.  Therefore, when you then try to update the state, Agile’s trying to work off of an older version of the same ECO.  
    You can prove this by adding int obj_versionX = eco.objectVersion() or adding Boolean up_to_date = eco.isUpToDate() checks to your script.  

    Try adding the line eco.refresh() before the session.disableAllWarning(); line and see if that works.

    Nonetheless, I’ve read about bugs involved that make Agile throw the “This object has been modified” error, so if none the above tricks work for you, you may be facing something more complicated and will have to try different options like a POST event.

    • 5 answers
    • 0 votes
  • Agile Angel Asked on September 5, 2018 in Product Collaboration.

    Yes, I’d do a PX for this that either checks the object’s history tab or PX that does a quick database query check for the change (“select submit_date from agile.change where change_number = ?”).  Then if either method returns null, throw a new DSL Exception and block the Delete Object event type as Samalendu mentioned.  I can’t really think of any other way.

    • 3 answers
    • 0 votes
  • Agile Angel Asked on August 30, 2018 in Product Collaboration.

    Hi Jason,

    Your PX will need to determine last approver simply by iterating over the workflow table and going from there like in the below lines (I can’t think of a better way):

    List arraylist = new ArrayList()
    ITable workflowtable = change.getTable(ChangeConstants.TABLE_WORKFLOW)
    Iterator iter = workflowtable.iterator()

    while (iter.hasNext()) {
       IRow row=(IRow)
       String reviewer = row.getValue(ChangeConstants.ATT_WORKFLOW_REVIEWER)
       String signoffstatus = row.getValue(1111) //gets signoff status
       String processtatecode = row.getValue(3934) //gets current status or previous status, etc.

       if (processtatecode == “Current Process” && signoffstatus == “Awaiting Approval”) {
    } //done iterating through workflow table

    if (arraylist.size() == 1) {
                    obj.logMonitor(arraylist.join()+ ” is the last remaining approver for ” + eco_number)
                    //check for other fields and if invalid, throw an AgileDSLException to block the approval process, else do nothing an let the person approve

    • 13 answers
    • 0 votes
  • Agile Angel Asked on August 24, 2018 in Product Collaboration.

    True – I’m thinking about the technology solution here though certainly many of us think in either people or process terms that would make for a better, more comprehensive solution.
    The solution my screenshot example uses works to get the session’s current user (i.e., the user approving), the Deviation Originator, and then if the person approving is the Deviation originator and 
    closure statement field is null or blank, Agile throws an error and blocks the originator from approving.  The script runs for everyone else but since they (the current user signing) is not the Originator, Agile skips over that part in the script and just lets them approve.  Therefore, this same method can be applied to look at different fields for different users, like say getting their job titles and forcing different actions based off of someone’s job title.  Again, not to undermine good processes and good training, of course.

    • 13 answers
    • 0 votes