How to update a BPL proces using business rule.

Question

Question

Tom Philippi · Nov 21, 2017

Initial questions have been answered. Expanded the post with actual code (see below)

So, I'd like to update one (and preferably) more context-fields in my ensemble BPL business process based upon the information in the request that initiates said BPL proces. I got a few questions about that:

1. First, I can't get it to work. Specifically, in the BPL process I call the business rule with my request as context and expect it to put it results in context.Boolean. The business rule nicely updates the context.Boolean but the conditional logic looks at specific fields in the request (i.e. if request.MyField="helloworld" then return true otherwise return false) doesn't work: The business rule always returns false. I suspect that the syntax I use in the conditional isn't entirely correct. (i.e. I am trying 'request.MyField = "helloworld").

2. Is it somehow possible to use one business rule to update multiple context fields in a BPL process? For instance, by trying to assign context.Boolean = true instead of returning true?

3. I could also solve this issue by implementing a Lookup Table or with a data transformation, but I have the feeling that a business rule is the nicest way to solve this particular problem. Are there any best practies when to use either a look up table, a data transformation, or a business rule?

Edit:

Okay, so let's work out what I am trying to achieve. I have a business process which receives an EventCode in the request message. Based on the EventCode I need to determine whether I need to create a Case (via a business operation) and I need to add the description of the EventCode to that call. There are a total of 150 EventCodes. Now, our business finds it challenging to determine which event code should result in a call and which one shouldn't. Therefore I expect to continuously review the list of codes together with the business while testing the implementation.

So what I have done so far is to add two context variables to my process:

- context.CreateCall As %Boolean to determine whether I should send a call.

- context.EventDescription As %String to write the description in the call.

Now, what I want to do is to transform request.EventCode to context.CreateCall and context.EventDescription, but I want to do it in such I way that I keep an overview of what I do with which event code and that I can discuss this overview with the business. I have the feeling that business rules are best suited for this. In my eyes a data transformation won't give me the overview and with a Look Up table i'll end up with two tables (again no overview).

So I am trying to configure my Business Process and rule. I want the rule to use the EventCode from the request message and then fill the context fields of the BPL process. However, as far as I can see the condition "request.EventCode=2103" doesn't trigger even though the EventCode is set to 2013 for a process. Please find the code below:

This is the code of my business rule:

And a snippet from the Business Process calling the rule:

..

Discussion (5)1

Log in or sign up to continue

David Loveluck · Nov 21, 2017

Before answering the specific questions, i will explain what business rules are for. (Routing rules are another story). Rules were invented to allow people who were not programmers to change code dynamically on a running system. That put a lot of constraints around them. It is the responsibility of the developer of the BP that invokes a rule to make sure the analyst who dynamically changes the rules can't do any damage, no matter how stupid or how malevolent they are.

If you are a programmer and your code is going through normal dev/test/promote cycles then you should probably just write a method of a utility class to do the work. You can't do anything in a rule that isn't easier to do in code if you are a programmer. I will repeat that routing rules are another story.

to answer your points

1. You would have to post your code for a real answer but a few guesses.

a) you can put values into context properties with an assign elements

b) the value that you <return> goes in the Result Location specified in the rule activity of the BP.

c) make sure you <return> when you have finished and don't continue through following <when> elements.

2. yes. you just use mulitple <assign> elments

3. a) lookup tables are designed for the case where you want to translate a lot of values. For example if you have thousands of product codes and their descriptions, that might be fixed of maintained on a regular basis, then lookup tables are the way to go.

3 b) Data transformations are for when you have two structures that are similar but not quite the same. For example an invoice might be represented slightly differently in two applications but they are close and you want to move fields around between the two formats. A second example would be to change the values in a data structure, perhaps by using lookup tables to translate from the codes used by the sending application to the codes used by the receiving application.

2 0

score 0 · Answer 1 · 2017-11-27T07:40:12-05:00

Ok I have updated my question with the actual code.

I figured out how to work with the <return> value, and I think that the assign might work as well, but I just can't get the condition to work. I doesn't seem to trigger on "request.EventCode=2103" even though the BPL processes a message where the request.EventCode=2103.

score 0 · Answer 2 · 2017-11-27T07:36:37-05:00

Yes, I am aware that you can call a Transform and then fill the context in a BPL-process. It is very important trick I think. However, I have the feeling that a business rule will be more manageable than a data transformation assigning values to 150 different codes.

score 1 · Answer 3 · 2017-11-23T08:14:52-05:00

I may have misunderstood your requirement, but you may not need a Business Rule at all. To pull data from the request into the context I've actually used Transforms.

To get this to work, I created a new class that Extends (%SerialObject, %XML.Adaptor), and defined in it the properties that I need to store. I could then define a Transformation from the incoming message type to this new one, pulling everything I needed. In the BPL I then added a property called "TempStore" of that type to the Context object in my BLP. To pull the data I added a Transform Activity with a Source of "request" and a Target of "context.TempStore" using the Transform.

Later Activity boxes could then use the fields with references like "context.TempStore.priorMRN" to do tests, etc. I've also used the same trick to update outgoing messages with data from the context (using Create = existing in the Transform).

I hope this is useful.

Regards,

Mike

score 0 · Answer 4 · 2017-11-27T15:04:10-05:00

Ok, I figured it out. Turns out I had to set the context of the business rule to BusinessProces.Context (and context with a capital C). The business rule then detected all my context variables when filling out the rules. Importantly I found that if you return a string value you must include "" and when you return a boolean you must use 0 or 1 (true or false doesn't work). Here is the code i used:

When calling the rule from the business process I used:

Important here is that if you include a resultLocation, you must give a return value in the business rule otherwise the value context.CreateCase is cleared (it had a default value of 0). Also, notice that the resultLocation is not required. An alternative implementation is to leave it empty and use assign in the business rule for both EventDescription and CreateCase.