Convert it to a dataset first, and then you can use WriteXML to dump it without having to loop through the rows.
So it turns out the email is not being sent because the condition fails…more on that below, first…
I’m not saying the “less spam” idea is bad, it may work for some companies better than others and depend on the circumstance (timing, frequency, urgency), the main point is Method Directives are supposed to work the same in Classic as Kinetic/Web-UI and this is a general problem with Conditions, (not sending emails)
Okay, back to the situation, here is my oh so simple method directive:
The conditions logic is this:
It seems to me that the issue is there is no queryResultDataset in Kinetic Web-UI,
However, if you look at the trace in Kinetic it does show a view (Ctrl-Alt-View in Debug mode) called OFBPreflight_0_0 and OFBPreflight_0_1
this sounds wrong. I don’t think it is true.
You probably need to report it with very simple UBAQ/BPM attached for the investigation.
Meanwhile you can use some other condition, like check DB instead of checking incoming tableset.
My main suspicion is that in classic, there are 2 records set from the client - before changes and changed. And maybe the condition you use relies on this information.
In REST it is not required and overall should not be used, because server should not rely on info sent by client. But maybe in your case it is essential for condition to work.
That is an interesting statement. I don’t think an inconsistency like that is acceptable.
When your condition is based on whether something changes or not, how would you trigger that then?
you know how - look in DB.
My point is when you get record from client it may contain anything, and you rely on its content here.
that is why this needs to be reported.Also I can be just wrong about reasons.
That’s all well and good in theory, but it’s designed the other way in Epicor for convenience, and now they’ve broken it.
WHAT?! @Olga is NEVER WRONG!
I agree…how will conditions work ?
if you look at the the Dataviews in Web UI there is OFBPreflight_0_0 (the “before” I assume) and it’s populated with each row, there is also OFBPreflight_0_1 (the “after” I assume) which is empty
I opened a ticket with Epicor last week on this, the are (gradually) working on it
at least 25+ years ago. And still supported for backward compat,
But I would tell security considerations changed a lot since then,
Help me understand “look in DB”, I assume you mean custom code ?
I am trying to detect a change, I need the before and after, how would I do that ?
(plus I still don’t like it, it’s been stated by Epicor BPMs work the same way in Classic and Web-UI, nobody wants to keep having to solve things two different ways in two different environments.
(We are trying to move to Web but this takes time, plus when things like this break it still takes time to analyze and fix)
Query to check table field value
There’s a few posts on the Before Image stuff that might be helpful:
But basically the before Image snapshot (from progress) was at one point adapted into the SQL Uplift and its how epicor does the “Field Changed from X to Y” it just means you get the same row twice one with and one without changes. Sometimes in BPMs you have to even do it yourself like in the above example.
Then Epicor literally does a little LINQ query comparing the Before and After fields to see if it changed. This was done automatically for you in the classic client via the Adapter (you didn’t have to do the before image injection yourself).
I guess in the web client they aren’t injecting the before image row on all the calls automatically as @Olga pointed out this probably should be reported and I suspect Epicor can change the way those Field Changed from X to Y widgets work to do lookups on the Db.
However for a BAQ that would be tough since the entire BAQ dataset is in memory it isn’t a single table it is a “view” generated by you so they’ll probably have to change the web client to send the BI at least for UBAQs otherwise I’m not sure they’ll ever be able to reliably tell that something changed (or didn’t)
I honestly think it may be a bit of a technical limitation (at least for a while) and we’ll have to work around it. (Assuming that is in fact what is happening)
1 Like
UBAQ Update in fact has nothing to do with BAQ itself. It is just one row that is sent to server and is used in BPM as data. BAQ dataset at this point is only on the client.
Wrote a quick UBAQ and indeed Epicor is still looking for that BI to determie changes here’s the code that widget uses
return queryResultDataset.Results.Any(r =>
r.Updated()
&& string.Equals(r.Customer_Name, "Larry", StringComparison.OrdinalIgnoreCase)
&& queryResultDataset.Results.Any(r1 =>
r1.SysRowID == r.SysRowID && r1.Unchanged() && !string.Equals(r1.Customer_Name, r.Customer_Name, StringComparison.OrdinalIgnoreCase)));
It looks at any “Updated” rows in the dataset compared to any “Unchanged” rows in the dataset that have a matching SysRowID.
When you do a network trace in Kinetic if you don’t see two rows coming in that call that explains why it isn’t working (and should be reported as a bug)
I’ll raise it on the CR too (once I have a chance to test it)
6 Likes
Hi Jose, curious did you get a chance to test and submit CR ?
thx
Not yet but its on my todo
Done and done and accepted by development in the CR
PRB0272874
1 Like