Temporarily disable BPM directives -- from a directive? E10.2.200

Epicor ERP 10
1

Hey all,

Here’s the situation:

  • Quote detail records customized for parent/child relationships
  • If I delete a parent, I also want to delete the child rows
  • I have a quote.update post-process directive that gets a copy of the ds and marks the rows I want to delete – .RowMod = “D”
  • When I update the ds it fires the pre-process directives again

How do I temporarily disable directives while the dataset updates?

Here’s some code I was using. I get a null reference on the update (commented out). If I update using the BPM BO Method object after this code runs I get the directives firing again.

// remove child lines

Erp.Contracts.QuoteSvcContract boQuote = Ice.Assemblies.ServiceRenderer.GetService<Erp.Contracts.QuoteSvcContract>(this.Db, true); // had a suggestion to add this 'true' flag, but then I get the error on the update so I don't know if it works

var quoteNumber = (from QuoteHed_Row in ttQuoteHed select QuoteHed_Row.QuoteNum).FirstOrDefault();

dsTemp = boQuote.GetByID(quoteNumber);

string check = "";
string deleteList = callContextBpmData.Character15;

string delimiterChar = "~";
string[] stringSeparators = new string[] { delimiterChar };
string[] deleteListAry = deleteList.Split(stringSeparators,StringSplitOptions.None);

int length = deleteListAry.Length;

if (length > 0)
{
  for (int x = 0; x < length; x += 2)
  {
    int quoteNum = Convert.ToInt32(deleteListAry[x]);
    int quoteLine = Convert.ToInt32(deleteListAry[x+1]);
    
    var QuoteDtl_xRow = (from QuoteDtl_Row in dsTemp.QuoteDtl
    where QuoteDtl_Row.Company == Session.CompanyID &&
    QuoteDtl_Row.QuoteNum == quoteNum &&
    QuoteDtl_Row.QuoteLine == quoteLine
    select QuoteDtl_Row).FirstOrDefault();
       
    if(QuoteDtl_xRow != null)
    {
      QuoteDtl_xRow.RowMod = "D";
      check += quoteLine.ToString() + "~";
    }

  }
 
  //boQuote.Update(ref dsTemp);           // get a null reference error
 
}

this.PublishInfoMessage("delete list: " + check, Ice.Common.BusinessObjectMessageType.Information, Ice.Bpm.InfoMessageDisplayMode.Individual, "", "");
2

You might consider using UpdateEXT instead of Update… it is designed to take care of things… below is a snipit of psudocode as a sample that deletes entries from UD12… this can even be done with a widget instead of c# code. Widget 1: fill ud table, Widget2: call updateext business object.

{
var DelUD12 = new Ice.Tablesets.UD12Row
{
    Company = orderInfo.Company,
    Key1 = OrderNumStr,
    Key2 = someothervalue,
    Key3 = "",
    Key4 = "",
    Key5 = "",
    RowMod = "D",
};

ds.UD12.Add(DelUD12);
RecordsFoundToDelete = true;
}
    
  
if (RecordsFoundToDelete)
  {
  using (var svc = Ice.Assemblies.ServiceRenderer.GetService<Ice.Contracts.UD12SvcContract>())
    {
    bool errorOccurred=false;
    BOUpdErrorTableset boUpdateErrors = svc.UpdateExt(ref ds, false,true, out errorOccurred);
    }
  }
3

Hi Tim,

Thanks for your reply. I’ll tuck that nugget away.

I had used something similar to get the rows deleted, but it didn’t update the quote tree data, so I’m getting an error after the update when it tries to display the tree again.

I got the error even though I refresh the ds as the last part of the post-process directive.

It works except for that minor issue. Maybe I can convince the customer they need to just disregard the error. :slight_smile:

I tried a customization that refreshes the tree panel in the quote dtl dataview notification, but it comes to late, I guess.

I didn’t see a widget to update the tree from the directive. ??

Thanks,

Joe

4

Hey @timshuwy, would you be able to expand upon the difference between UpdateEXT and Update? I’d love to know more about why two seemingly similar methods would be used for different purposes

5

In a nutshell as I understand it - Update is rigid, you must pass EVERYTHING needed, UpdateExt is “smart”, it can figure things out based on context. Essentially, if you give UpdateExt enough info, it will automatically look up the rest so you dont have to supply it.

2 Likes
6

The UPDATE process requires the entire record to be passed to the method… this means that you must read the record, modify it, and then pass back the entire record.
The UpdateEXT process is a wraps around the update process, and it allows you to only pass the data you want to change. UpdateEXT then automatically does the work of reading, updating, and writing the data. You are only required to populate the “required” fields for that transaction.
Example, if you know that you want to update the Part.MyUDField_c on a Part, you simply need to populate the Company, PartNum, and MyUDField_c fields with the data… then call Part.UpdateEXT. you new data will be passed and will update the part table.

6 Likes
7

OH… one more thing… You can associate BPMs directly to UpdateEXT, and they will only fire when UpdateEXT is called…
BUT
When you call UpdateEXT, then it automatically calls UPDATE, and so all BPMs associated with UPDATE will then run. This means that UpdateEXT will still fire all the UPDATE BPMs.

2 Likes
8

Another “why” has to do with updatable BAQs and Service Connect. Anyone wanting to get beyond the basics of either of those would be advised to become familiar with UpdateExt because they’re key to using them effectively.

1 Like
9

You bring up a good point… if you want to see examples of how UpdateEXT is used, you can “simply” create an updatable BAQ… then look at the code in the UBAQ BPM that is generated automatically for you… But now, if you look, (to quote Disneyland) “ye seen the cursed treasure”… image

5 Likes