RuleService - output

[magick93]

Hi

I have read - many times - the RuleService documentation, and can see how to insert global variables into the rule service.

How do I, using drools, insert a fact, and get this out of the RuleService?

thanks and regards,

[kcbabo]

IINM, the current way to do this is to use the global reference to message in your rule definition to set the content in the consequence of your rule.

global org.switchyard.Message message

rule "Example"
    when
        ...
    then
        ...
        message.setContent(stuff);
end

Another thing to keep in mind is that if you are inserting and returning the same Java object (e.g. your rule sets a field value on the inserted object), the default behavior of the rules component is to return a reference to the original content that was inserted.  In this situation, you could modify the inserted object in your rule consequence and that modified version would be returned from the rules service invocation.  Make sure your service contract (interface) for the rules service is in-out in order to get this behavior.

David is the expert here, so I'm sure he'll correct anything I got wrong above.  We should add something to the documentation which specifically addresses this question.

[dward]

Keith is correct. One thing I will add, however, is that even though the message itself is available as a global, it is not a "fact" in the true sense of the term. (It will not trigger a LHS.) The *content* of the message is executed as a fact to the drools engine (KnowledgeSesion).

FYI, there has been interest in being able to add a <facts> section in the config, so you can use expressions to specify what you want added to the session (much like we have a <globals> section). This in contrast to the message content itself having to be a "holder" object containing all your facts which your rules then have to traverse in their LHSs.

[dward]

Here is the jira: https://issues.jboss.org/browse/SWITCHYARD-1028

[magick93]

Thanks David

We are moving to use the SwitchYard RuleService, but have many drools rules already written, and most of these use the idea of inserting facts into the Drools Working Memory.

So we certainly welcome the possiblity of a <fact> config section being developed.

Kind regards,

[dward]

NP. I coded this up this morning. Just waiting for github to come back online.

In the meantime, a question for everyone...

If the result of the fact mapping expression is a Collection, should the whole Collection be inserted as a single fact (as of now that's how it's coded), or should SwitchYard iterate over it and insert each element separately as facts?

Depending on the answer, will only take a minute or two to change and test.

Thanks.

[dward]

After some thought, I think the right thing to do is unwrap results of expression mappings that are instances of Iterable, inserting each iteration as it's own fact. We can open a separate jira in the future if this decision gets overturned.

[jeffdelong]

Yes, that is how it should work. The collection should be unrolled (as it is in JBoss ESB). Dealing with collections in rules in more complex than working with individual facts.

Thanks.

[dward]

Schweeeet. That's how the pull request was submitted. Thanks for the feedback!

[jodonya]

David

I was trying to compile the updated rule component to use the new  fact feature and ran into this,

components/rules/src/main/java/org/switchyard/component/rules/exchange/drools/DroolsRulesExchangeHandler.java:[195,66] cannot find symbol

symbol  : method getProviderOperation()

location: interface org.switchyard.metadata.ExchangeContract

[INFO] 1 error

I just replaced the line 195 in DroolsRulesExchangeHandler.java with

  ServiceOperation serviceOperation = exchange.getContract().getServiceOperation();

Hoping you meant to write getServiceOperation() and not getProviderOperation() because atleast it allowed me to compile the rule component, may be you can have a look at that part

Regards

[dward]

Japheth,

No, getProviderOperation() is correct.  There was a switchyard-api change in core that preceded this switchyard-component-rules change in components.

If you are building from scratch, I suggest building all of parent, core, components, quickstarts, console and release (each SwitchYard git repository) - and in that order.

However, you shouldn't need to build anything, if you are using the SwitchYard 0.6.0-SNAPSHOT jar versions of each project from those repos, available pre-built in the JBoss Maven Nexus repository already.

David

PS: Yes, I've edited this response 4 times now. Coffee hasn't kicked in yet...

[kcbabo]

As David mentioned, you definitely can build the components repository standalone.  My guess is that you have a stale/old version of core artifacts in your local Nexus repository.  Try using "mvn -U clean install" in your components build.

[magick93]

Hi Keith and David

Many thanks for your help on this issue.

Im having trouble understanding how I can insert facts - and then retreive those outside of drools.

Using your example in the jira ticket:

class Policy {
Driver driver;
Coverage coverage;
}

So, in drools, if I insert a fact, it would look like this:

Policy fact0 = new Policy();
fact0.setCoverage( "This is new coverage etc" );


insert( fact0 );

How can I insert multple new policy facts, and then access them in SwitchYard?

[dward]

Anton, please see the document section called "Mapping Facts" here:

https://docs.jboss.org/author/display/SWITCHYARD/Rules+Services

You could have a SwitchYard Message's content be a Collection<Policy> itself, and then not have to provide any <facts> mappings, or you could have the Message content be a PoliciesHolder (or whatever) like this:

class PolicyHolder {

    Collection<Policy> getPolicies();

}

, but then you would have to specify <facts><mapping expression="message.content.policies"/></facts> (in this case, "message.content" resolves to PolicyHolder)

In either case, your rule would look like:

rule "policy rule"

when

    $p : Policy()

then

    $p.setCoverage("whatever");

end

That rule would fire for every Policy within the Collection<Policy>, since Iterables are unwrapped and every element is inserted.

Make sense?

[magick93]

thanks David

Yes I have read the documentation many times - I almost have it memorized. But there is still some grey areas, so I greatly appreciate your input.

In your example above you are modifying - and not inserting. We have many existing rules that use insert.

From my understanding, we need to retreieve the inserted object in the mappings by name, so in the above example, that would be fact0.

But, we often do not know the name of the variable. There are many rules, and the analysts change rules.

Is this a limitation in SwitchYard, or in my understanding?

Thanks again for your support.