JBossDeveloper

I must have misunderstood what you are trying to do. I thought you were saying you didn't know how to insert facts using SwitchYard.

Are you instead asking how can you get facts that are inserted within the rules out of the executing session, using SwitchYard?

If that's the case, then every fact that you insert should also be added to a global variable.  Here is an example doing this:

class PolicyHolder {

    Collection<Policy> getPolicies();

}

<implementation.rules>

    <globals>

        <mapping expression="path.to.your.policyHolder" variable="policyHolder"/>

    </globals>

</implementation.rules>

global com.example.PolicyHolder policyHolder

rule "policy rule"

when

    // whatever your conditions are

then

    insert(policy);

    policyHolder.getPolicies().add(policy);

end

After your rules are done executing, your PolicyHolder will have been populated with Policies.

The example is an explicit global mapping to the PolicyHolder.  Of course, the SwitchYard Message content itself could be a PolicyHolder, in which cases the <globals> mapping wouldn't be necessary, as the Swithcyard Message is always available as a global variable in your rules.

So it would be like this:

global org.switchyard.Message message;

rule "policy rule"

when

   // whatever your conditions are

then

   insert(policy);

    PolicyHolder policyHolder = (PolicyHolder)message.getContent();

   policyHolder.getPolicies().add(policy);

end

The Message content is then available as the return object in an IN_OUT scenario.

Last variation is that instead of a Collection<Policy>, it could be a Map<String,Policy>, so you can dynamically add Policies by name in your rules.  Same thing applies, though, that it needs to be a global mapping itself, or something contained within a global mapping.

Am I now understanding your issue properly?

The whole purpose of Globals in Drools is to have a shared space for data, and SwitchYard supports that.  It is "the sanctioned way" of doing this sort of thing, rather than frameworks implementing their own mechanism.  So I don't believe there is a limitation being imposed by SwitchYard here.  (Not being defensive; just explaining why it is the way it is.)

I understand - and agree - that forcing analysts to learn DRL and modify lots of it is not a good idea.  So... here's an option: Why not write some DSL that does what you need?  The DSL could be short and sweet and human-readable, but under the covers does both the insert into working memory, as well as adding it to the global?

Or you could write a function...

Anton Hughes wrote:

 

'ride the sacred goat of happiness'

LOL.

Yeah, I understand.  Thanks for your interest and feedback.  It's very much appreciated.

Anton,

You can still use working memory operations to insert facts into the working memory created by Switchyard. They are just not available to other Switchyard services without adding them to the message. This is no different from a typical Drools application. If you insert a fact into the working memory from the consequence of a rule, you first have to create the instance use a contructor and then call insert. In this case it is not available to the Java class that called it.

Only if you need to access these new facts as Java objects outside the working memory do you need to add them to the message, or use a global, etc.

So I would not expect you to have to re-write your rules.

Jeff

Anton, I can whip together an example of this, but if it's okay with you, I'm gonna do it against 0.7 (which is available in Nexus, but just not yet publicized until we finish our final round of testing).  I mention this because the configuration of the bpm and rules components has changed between 0.6 and 0.7.  Considering I'm testing 0.7 anyway, I can use this as part of my manual testing.   Does this sound okay with you?

Anton,

I'm attaching a simple example I created using the SwitchYard 0.7 eclipse tooling.  It shows the same rules switchyard service being executed via a java interface, and via a soap endpoint.  In both cases, it is an IN_OUT service.  Please refer to MyTest.java as a good starting point.  In the first test, the service is invoked by passing in a Widget where the processed flag is false.  In return, you get a Widget where the processed flag is true.  Who processed it? MyService.drl, of course.  In the second test, the same service is executed, but this time by sending a soap message in, and gettting a soap message back.  Same thing happens, but obviously there is xml tranformation done by switchyard.

The key is in the action input mapping, where the message content is made available to the rules engine as a fact.  (This is because it is an <inputs><mapping>.  For it to be a global, it would be a <globals><mapping>, and a variable name would have to be assigned to it, and the drl would have to declare the global.  But I digress...)  Inside MyService.drl, you see that the rule is triggered simply by there being a Widget available in working memory.  Then, the object is mutated by the consequence side of the rule.  $widget.setProcessed(true). That same Widget, which is still the content of the message, is sent back by SwitchYard.  This is really just one way of accomplishing "getting values out of a Rule Service".

Hope this helps,

David

Anton,

Don't confuse ExchangePattern (which has IN, OUT, IN_OUT) with Scope (which as IN, OUT, EXCHANGE).  An ExchangePattern describes the message interaction between participants (ie: client and server), a Scope describes the applicability of Properties within a Context.

Both the java service interface (which has a return value and is invoked with the invoker.sendInOut), and the soap wsdl (which defines both input and output), describe the service as IN_OUT. However that's not how the return parameters is determined.  In the absence of specifying an <outputs><mapping>, the code defaults to sending out the same content that was sent in (the modified Widget).  So that's how that worked out. Again, there are multiple ways to peel this onion (and I don't have the bandwidth to code all of them for you).  This is just one way.

To answer your specific questions:

1. Yes.  Multiple <mapping>s can be placed under <inputs>.
2. Use <outputs> when you want to be specific what gets outputted rather than depending on default behavior.
3. message.content (or the result of any expression) can be anything, but you are responsible to make sure it is of the correct type before it gets cast.
4. You don't do the casting. Reflection is used. Just make sure your MVEL expression results in the appropriate object of the appropriate type (the type you declared in the drl global)
5. See my note above about ExchangePattern vs. Scope.

David

There could be multiple reasons why your change didn't work:

1. Did you update your client (invoking) code to match?
2. If using SOAP, did you update the WSDL to match (as well as the soap-request.xml and soap-response.xml files)?
3. Did you update the application's transformation code to match?

That's just a few right off the top of my head.