Data Directive is being skipped?

[elfrykman (Eric Frykman)]

@Rick_Bird

@elfrykman
I can really appreciate what you are trying to do here… makes sense.
For troubleshooting this, put a BPM on the Method Call that you expect (In Theory) to create your record and just have it pop a message when it’s hit with all the various variables/arguments and data set… to confirm it’s actually getting it… your Theory may not be correct, or the method is failing to make the create… or there is another broken link in your chain of method calls.
I’ve seen something like this before.
To @jkane point… if it’s available you might need to use the ‘Complete Call’ widget to close out this call and then enable another Directive to pick it up? Grasping at Straws

I didn’t see a Complete Call widget in the Standard area of the BPM.

I guess I’ll have to add a bunch more widgets to the process, and based on the reaction I had in this thread, I’ll be sure to share it.

[klincecum (Kevin Lincecum)]

@elfrykman

Is there a way to see if the process is bypassing the facade?

I don’t think there is a direct way, but I could be wrong.

You could set a variable in a pre-processing. If it isn’t set, then…

[Chris_Conn]

I did not look too deep, but I am just referencing this.

I guess in fairness most of this is message boxs and set fields.

Just be aware that any overhead you add to an in-trans will be a speed bump for every transaction.

Is there a way to see if they are disabling triggers? Not off hand aside from just wading through thousands of lines of decompiled code. Best suggestion I would have is to write a simple log and review it to get an idea of when it does and doesnt fire.

Ice.Diagnostics.Log.WriteEntry(“MY VALUABLE INFO HERE”);

Then find it in your event viewer.

[elfrykman (Eric Frykman)]

@Chris_Conn

You should either ensure you can do everything you need async, or queue this up to be handled outside of the initial transaction.

Your comment here got some wheels turning, so I set the function I made to do the record creation to run async. The result looks like it DOES run through the Lot selection logic, but I can’t be 100% certain as none of the pop ups I have in place are firing. However, the resulting transaction does have a Lot assigned to it.

I did some more work and was able to figure out a way using the Reference field to find the previous record and set that Lot to be skipped. It seems to be working as I want it(!!!). I need to do a bunch more testing with different scenarios to make sure it doesn’t break, but this is extremely promising. Still a little weirded out on how none of the pop up messages fire, but I can live with that if my output is correct.

Thanks to everyone for the help, even if your responses were just memes . Sometimes typing it out is all it takes to find the answer yourself.

[CSmith (Clint Smith)]

@elfrykman

none of the pop ups I have in place are firing

You cant popup in server side code fyi.

[klincecum (Kevin Lincecum)]

Well you can, if the call comes direct back to the client. A data directive, especially one calling other stuff, the chance is slim to none for that to wire up and work correctly.

[CSmith (Clint Smith)]

AFAIR he was using function call, I know you can make log messages but not popups in functions

[klincecum (Kevin Lincecum)]

Believe it or not, they work sometimes if direct in the chain.

[elfrykman (Eric Frykman)]

@Chris_Conn

Best suggestion I would have is to write a simple log and review it to get an idea of when it does and doesnt fire.

Ice.Diagnostics.Log.WriteEntry(“MY VALUABLE INFO HERE”);

Then find it in your event viewer.

This was immensely helpful to my next layer of troubleshooting.

In the scenario where I have only 1 lot without enough qty, I get the second record generating exactly as I need. However, if that second lot doesn’t have enough qty to fill the remainder the logic doesn’t go any further.

What I found, using the log write, is that the callContextBpmData.Number01 field I’m using to feed into the function is zeroing out from the In Tran and the Standard. I can see the qty there as it enables the Standard, but changes to 0 at the very start of the standard. Any idea why that data would change in the middle of the BPM? This is all new to me.

[klincecum (Kevin Lincecum)]

@elfrykman

Any idea why that data would change in the middle of the BPM? This is all new to me.

Not entirely, but I’ve had the same trouble. It seems the context is changing somewhere.

[CSmith (Clint Smith)]

Ya, that’s why I suggested he handle recursion IN the DD since he started it. Sometimes depending on the logic trigger they are not direct relations for the purposes of the callContextData.

[elfrykman (Eric Frykman)]

I would love it if the BPM designer shifted to something more in line with Automation Studio as it’s super easy to do recursion there. Doing all of this inside the In-Tran part sounds like a huge amount of code that I’m not even sure would work. I wasn’t able to get the new record to behave until it went async.

[elfrykman (Eric Frykman)]

@klincecum

@elfrykman

Any idea why that data would change in the middle of the BPM? This is all new to me.

Not entirely, but I’ve had the same trouble. It seems the context is changing somewhere.

Really odd. I can watch it go to 0.0 at the very start of the standard part of the DD.

Any tricks on sending data from an In Tran to Standard outside of the call context?

[klincecum (Kevin Lincecum)]

@elfrykman

Any tricks on sending data from an In Tran to Standard outside of the call context?

Tags.