How can I relate a ds parameter in BPM to table it belongs to in order to use related fields?

I’m trying to create a BPM that will throw an error message when a user attempts to change an Operation in Engineering Workbench that is not marked as Subcontract in the OpMaster when ECOOpr.Subcontract = true.

I’ve done the trace and see that the first method where the “new” operation is referenced is on ChangeECCOprOpCode, but it’s called out in the ds parameter “proposedOpCode” (trace code snippet below).

So my question is how can I use that parameter to pull the related OpMaster.Subcontract to check if that is set to true/false for the OpCode they are trying to change to?


<businessObject>Erp.Proxy.BO.EngWorkBenchImpl</businessObject>
  <methodName>ChangeECOOprOpCode</methodName>
  <appServerUri>**removed for security**</appServerUri>
  <returnType>System.Void</returnType>
  <localTime>4/17/2024 11:10:10:9722578 AM</localTime>
  <threadID>1</threadID>
  <correlationId>e20c8411-8eb1-4818-8286-fdb5a35bc640</correlationId>
  <executionTime total="112" roundTrip="67" channel="0" bpm="0" bpmDataForm="9" other="36" />
  <retries>0</retries>
  <parameters>
    <parameter name="proposedOpCode" type="System.String"><![CDATA[AV-CC]]></parameter>
    <parameter name="refreshMessage" type="System.String"><![CDATA[]]></parameter>
    <parameter name="ds" type="Erp.BO.EngWorkBenchDataSet">
      <EngWorkBenchDataSet xmlns="http://www.epicor.com/Ice/300/BO/EngWorkBench/EngWorkBench">

(Certainly there's a way to do it through custom code, but alas, I'm not a coder, so hoping there's a way to accomplish this with available widgets.)

You just need to retrieve data from a table? I think an Epicor Function would do just fine there.

Ditto.

You can use a condition widget and do a query there. You look for something that would cause an issue in the query, then you can make a condition based on how many rows come back in said query.

the caveat for these queries is that you don’t want to join to a TTtable (even though they show up, don’t use them). It can cause massive performance issues. So just set some variable(s) ahead of time, then use those to filter the table(s) you want to filter.

Then in the condition you set the number of rows and attach an exception to the true or false side depending on how you have your logic set up.

No coding needed!

1 Like

Ok, this is the route I was taking (minus the variable), but not having success with it… probably because I was joining the TTtable and not using a variable. Will give that a go.

I assume the variable is set to the parameter?

I do already have it setting a BPM Context Field so that I could put it in a message to make sure it was passing the correct info.

@d_inman I do these checks on Update like @Banderson’s example. You can even check the entire BOO not just this op for the issue.

True, that’s better/simpler. You don’t need the actual value of the data; just a test if it’s true, etc.

Variable, or whatever piece of information to look for whatever you need to look for. You can get it from parameter, TTtable etc. You have options in here to pick from.

image

I missed what you said here. But, you still have to know how to get the data from a function, so other than being reusable, I’m not sure how that would help you.

Yep, exactly what I was doing, too. My brain simply didn’t put the two together to try to accomplish what I am.