1 2 3 Previous Next 30 Replies Latest reply on Jan 10, 2013 11:47 AM by Anton Hughes

    RuleService - output

    Anton Hughes Master



      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,

        • 1. Re: RuleService - output
          Keith Babo Master

          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"


          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.

          • 2. Re: RuleService - output
            David Ward Master

            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.

            • 4. Re: RuleService - output
              Anton Hughes Master

              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,

              • 5. Re: RuleService - output
                David Ward Master

                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.



                • 6. Re: RuleService - output
                  David Ward Master

                  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.

                  • 7. Re: RuleService - output
                    Jeff DeLong Master

                    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.



                    • 8. Re: RuleService - output
                      David Ward Master

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

                      • 9. Re: RuleService - output
                        Japheth Odonya Newbie


                        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



                        • 10. Re: RuleService - output
                          David Ward Master



                          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.




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

                          • 11. Re: RuleService - output
                            Keith Babo Master

                            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.

                            • 12. Re: RuleService - output
                              Anton Hughes Master

                              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?

                              • 13. Re: RuleService - output
                                David Ward Master

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



                                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"


                                    $p : Policy()





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


                                Make sense?

                                • 14. Re: RuleService - output
                                  Anton Hughes Master

                                  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.

                                  1 2 3 Previous Next