I'm working through one of the tutorials for using Corticon from the ABL (OE 11.3.1 008, Corticon 5.3.3), and was surprised when I got a syntax error from a line that a PDS macro added for me:
USING OpenEdge.BusinessRules.DecisionService.
I backtracked my work and found that I had missed the tutorial step for adding DLC/gui/rules/OpenEdge.BusinessRules.pl to my propath, and once I did that it worked fine. So it works, but it seems odd to have to adjust my propath for something that otherwise seems to be integrated into OpenEdge.
Is the need to add the propath entry a temporary thing, or is it something I need to plan for when it comes time to roll out ABL-Corticon integration for our customers?
Hi mopfer,
Business Rules pl should be added to project PROPATH explicitly, if user plans to call corticon decision services from OpenEdge.
Hope this Helps,
DivyaTheja
I understand that I am required to do that today. I think it is something that can be changed though, so it would not be necessary in the future, particulary for the deployed environments that OpenEdge production applications are running in. Anything that makes it easier for our customers to configure OpenEdge for integration with Corticon is going to make it easier for our customers to believe that integrating with Corticon is worth the time and expense.
We were trying to balance that simplicity with having every possible thing in propath (and possibly suffering from performance issues).
We do have a backlog story to make it easier in PDSOE to flag a project as being a "rules" project and to make it easier to add the relevant entries to pro path in the tooling.
-- peter
________________________________________[collapse]
From: mopfer [bounce-mopfer@community.progress.com]
Sent: Saturday, February 08, 2014 9:53 AM
To: TU.OE.Development@community.progress.com
Subject: RE: Will DLC/gui/rules/OpenEdge.BusinessRules.pl be fully integrated into the ABL at some point?
RE: Will DLC/gui/rules/OpenEdge.BusinessRules.pl be fully integrated into the ABL at some point?
Reply by mopfer
I understand that I am required to do that today. I think it is something that can be changed though, so it would not be necessary in the future, particulary for the deployed environments that OpenEdge production applications are running in. Anything that makes it easier for our customers to configure OpenEdge for integration with Corticon is going to make it easier for our customers to believe that integrating with Corticon is worth the time and expense.
Stop receiving emails on this subject.
Flag this post as spam/abuse.[/collapse]
Good answer, Peter. I think you are right that one doesn't want every possible thing in the PROPATH, but only those things that are actually used. But, making it more or less automatic when working with Corticon is a fine solution.
Are there any plans to integrate the Corticon adapter classes into the ABL?
Like that happened with the Savvion/OpenEdge BPM Adapter classes? Started a as prototype / initial version coded in the ABL, now become part of the ABL.
Thanks for the explanation. That makes sense, and I appreciate that performance is being considered, as that matters to all of us.
I'm actually less concerned with PDSOE than I am with the deployed environments though. As I developer I expect to have to do a little configuration in my IDE. However, as a person deploying application updates for an ISV, it would be nice if installing the latest version of OpenEdge included being able to get at the ABL objects for integrated access to Corticon without having to adjust the propath of every client and appserver that will potentially use those ABL objects.
Whether we do that manually or program something to adjust the propath within our application, that is the sort of thing that will break if the code moves to a different place inside OpenEdge someday. It seems like it would be better for the ABL to handle the location of its own objects itself.
But, if OE is deploying these things in .pls, including everything automatically, whether needed or not, is going to mean some long PROPATH's which are unnecessary. I've always managed things like this centrally, so adjusting the PROPATH for a new distribution is trivial compared to pushing out the distribution itself.
Are there any plans to integrate the Corticon adapter classes into the ABL?
Like that happened with the Savvion/OpenEdge BPM Adapter classes? Started a as prototype / initial version coded in the ABL, now become part of the ABL.
Flag this post as spam/abuse.