...
APEX policy development includes three parts - develop the state machine transition using APEX language (i.e. .apex file), develop I/O event schema to each state (i.e. .avro files) and develop processing logic in each state/task (i.e. javascript files). APEX policy developer should follow best practices to develop APEX policies and submit for git review once they are done. Then APEX command line tool can be used to generate the executable JSON for PDP-A.
TBC with Apex team
2. Policy Lifecycle API CRUD Enhancements
...
| PDP Engine | Content-Type | Description |
|---|---|---|
| PDP-D: Drools | application/vnd.onap.drools+text application/vnd.onap.drools.mvn+xml | Drools DRL text files. Question: Does Drools have a custom content-type already?? Maven XML dependency specification for a java artifact containing drools rules and required dependencies. Does maven have a custom content-type?? |
| PDP-X: XACML | application/xacml+xml; version=3.0 | Per http://docs.oasis-open.org/xacml/xacml-rest/v1.0/cos01/xacml-rest-v1.0-cos01.html |
| PDP-A: Apex | application/vnd.onap.apex+json | Apex JSON policy files. TBC with Apex team |
2.1 PDP-D Content-Types
chenfei
| team |
2.1 PDP-D Content-Types
Two Content-Types can be used by policy authors to create native drools rules - "application/vnd.onap.drools+text" and "application/vnd.onap.drools.mvn+xml".
"application/vnd.onap.drools+text" refers to native drools drl text contents. When drools authors use this Content-Type in POST call, they only need to provide drl text contents into its payload. One payload example is shown as below:
| Code Block | ||||
|---|---|---|---|---|
| ||||
Content-Type: applicaiton/vnd.onap.drools+text
package org.onap.policy.controlloop.ran;
import org.onap.policy.controlloop.event.SampleMsEvent;
import org.onap.policy.controlloop.ran.Enodeb;
import org.slf4j.LoggerFactory;
import org.slf4j.Logger;
declare Params
closedLoopControlName: String
end
rule "SETUP"
when
then
Logger logger = LoggerFactory.getLogger(drools.getRule().getPackage());
logger.info("{}: {}", params.getClosedLoopControlName(), drools.getRule().getName());
Params params = new Params();
params.setClosedLoopControlName("example-name");
insert(params);
end
rule "EVENT"
when
$params : Params( $clName : getClosedLoopControlName() )
$event : SampleMsEvent( closedLoopControlName == $clName )
then
Logger logger = LoggerFactory.getLogger(drools.getRule().getPackage());
logger.info("{}: {}", params.getClosedLoopControlName(), drools.getRule().getName());
Enodeb enb = new Enodeb($event);
enb.reboot();
retract($event);
end |
One limitation of "application/vnd.onap.drools+text" Content-Type is, the payload only contains native drl contents without other dependency information (i.e. dependency artifacts) also required to load into drools memory to support execution of the native rules. In aforementioned example, "SampleMsEvent", "Enodeb" and "Logger" are from other dependency artifacts. When Drools PDP-D receives this set of native rules deployed from PAP, it does not know how many dependencies to load into memory along with the rule itself to support the rule execution.
To bridge the gap, one solution is to use "application/vnd.onap.drools+text" Content-Type only when there is modification to the rules (i.e. updating the rules) and the new updates will not introduce new dependency. Given a set of rules are already running in PDP-D and all required dependencies are loaded as well, now we have new requirement that means to change a logic in one rule, e.g. changing to reset enodeb other than reboot,
2.2 PDP-X Content-Types
pam
...
Apex PDP will need to be able to ingest custom Apex JSON policies. TBC with that team - may already be well-supported.