How many business objects are you talking about?  Agile’s import utility is quite fast. It’ll create the object update the object if the field is mapped correctly and there’s an update to be made.  I feel as though that without API, Import utility will be well worth your time.

I was able to do this through javax.mail.  Google some examples of javax.mail and you should be able to find some answers for you. 
I am succesfully able to run a script from my desktop or within Agile SDK that imports the javax.mail* and javax.mail.internet* packages and emails whoever I need to – even creates a .csv file or other various attachments if I need it!  Note that your company’s email settings may detect this kind of email as spam but I didn’t experience an issue in my company to all of the internal employees. 

Google points like:  javax.mail, MimeMessage class, Transport.send() method, Internet Address for some examples. 

Let us know if you need help.

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

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

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.

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.

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;

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.

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?

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.

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.