11 Replies Latest reply on Dec 19, 2011 2:30 PM by Keith Babo

    SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final

    Murray Todd Williams Newbie

      I've been trying to take myself through Keith's (rather nice) video demo to get my feet wet with SwitchYard, and I've run into an interesting hitch. (Actually two, but one was trivial to resolve.)


      First, the environment I'm using is:

      • AS7.0.2
      • SwitchYard 0.3.0.Final installed on AS7 via the installer method
      • Seam Forge 1.0.0.Beta3 (reports itself as Forge 1.1)
      • Eclipse Indigo + JBoss Tools 3.3.0.M4 (not that this probably matters)


      I've followed along with the demo line-by-line. (Sometimes I changed the order just a bit, like including all three project facets—switchyard, switchyard.beans, switchyard.bpm—at the same time before creating the services or the bpm-service.)


      I've done this a few times now, although the last two times I did this, I got a new bug which I'll report now: sometimes the switchyard.xml file would get created and Eclipse would report an XML validation error. What happens is that the <service name="Greeting"> line woud get added before the

      <implementation.bpm xmlns="urn:switchyard-component-bpm:config:1.0" processDefinition="META-INF/Greeting.bpmn" processDefinitionType="BPMN" processId="Greeting"> line, which apparently conflicts with the Schema. Reversing those sections was pretty trivial, but I figure it was worth mentioning it.


      Now the real problem occurred when I tried running the unit test. When I ran it, the two messages that got written were "Hello, null" and "Goodbye, null". So obviously something was not getting the messages passed into the Hello and Goodbye services.

      As I said, I tried this a few times from the top, just to see if there was a set I was getting wrong. Then on a hunch, I decided to select the 0.2.0 SwitchYard version during the initial forge switchyard facet definition instead of 0.3.0.Final, and this time the demo worked.


      Just for good measure, I edited the POM of the working demo, changed the SwitchYard version from 0.2.0 to 0.3.0.Final again, rebuilt, ran the unit test again, and the demo broke again—HelloBean and GoodbyeBean were getting null once more.


      One last note: I tried updating the POM to use 0.4.0-SNAPSHOT and got the same null problem.


      Update: I created a SWITCHYARD-589 ticket about the XML error, since I was able to diagnose and reproduce the problem easily enough. Let me know if I should create a JIRA ticket for the overall demo null bug. Since I've got no idea what's going wrong, it's a little harder to describe it, but I'm happy to file this in the system if that's a more appropriate place.

        • 1. Re: SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final
          Keith Babo Master

          Hey Murray,


          Thanks for trying this out and filing the bug.  I will run through the demo as well and circle back if I don't see the same problem.




          • 2. Re: SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final
            Murray Todd Williams Newbie

            I tried looking through the BPM quickstart to see if I could understand how things work. (My challenge being that I'm a complete ESB/BPM newbie, so I don't really know how things are supposed to work.) Some items that might qualify as candidates:


            • On the generated unit tests, I tried changing @ServiceOperation("Hello") to @ServiceOperation("Hello.process"). (I suspect that if your service just has one operation defined, @ServiceOperation will assume that as the default and not require the fuller form. But as I said, I'm a newbie and don't really know what I'm doing.)
            • In the BPMN graph, I similarly set the ServiceOperationName to process for both. (Again, I don't know if this is necessary for one-operation services)
            • In the BPMC graph, I noticed in the quickstart that there was some variables messageContentIn and messageContentOut defined, and the services had {messageContentIn=messageContentIn} and {messageContentOut=messageContentOut} defined as the Parameter Set and Result Set, respectively. I tried doing the same thing on my Hello and Goodbye services, and the first one appeared to run as expected, but Goodbye was still getting a null value.


            Couldn't quite get everything to work as needed, but I'm learning a lot while I fiddle!





            • 3. Re: SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final
              Murray Todd Williams Newbie

              I was just going through the Asia Workshow lab slides, and one thing occurred to me: in the BPMN2 editor in Eclipse, if I'm using Switchyard 0.3.0 I don't see InputMessageVariable or OutputMessageVariable in the properties section for a SwitchYard node.



              I checked the raw XML in the .bpmn file when setting this up under 0.2.0 and 0.3.0, and from what I can tell, the BPMN graph is identical. I'm guessing the automatic binding of input and output variables isn't happening in 0.3.0.


              I think I have enough clues here to file a JIRA ticket...

              • 4. Re: SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final
                Keith Babo Master

                Ah, one thing that changed in 0.3 is we are now using the native parameter/result mapping in jBPM instead of defining our own method (InputMessageVariable, OutputMessageVariable).  You can see this in action in the bpm-service quickstart.  The video I did pre-dated this feature.

                • 5. Re: SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final
                  Murray Todd Williams Newbie

                  Hmmm, then I guess I haven't quite figured out what's going wrong yet.


                  I'm guessing this new system has something to do with the Parameter Mapping {messageContentIn,messageContentIn} and Result Mapping {messageContentOut, messageContentOut} properites that I see in the quickstart's SwitchYard nodes. When I try to create a BPMN2 graph manually (again, following the process shown in the video) nothing gets automatically populated in those properties—they just show up as empty {} property/variable pairs.


                  I tried setting them manually, but it didn't seem to work. (I also didn't know what I was doing, i.e. whether I was supposed to define some messageContentIn/messageContentOut variables for the overall composition, etc.)

                  • 6. Re: SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final
                    Keith Babo Master

                    I walked through the steps in the video with 0.3.0.Final and was able to run the unit test successfully.  There's one change from the steps in the video and that is to use the built-in jBPM support for parameter mapping.  To do this, I added a process variable definition to the process itself and then a parameter mapping definition on the calls to Hello and Goodbye in the process.  I was able to do all of this using the visual editor, so you don't have to mess with the XML unless you really want to.  Updated project attached.


                    BTW, I filed a JIRA to add the variable to the generated process definition by default.


                    • 7. Re: SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final
                      Murray Todd Williams Newbie

                      Okay, thanks. I'll take a look at that in a few hours (I'm popping off for a holiday lunch) and I'll see if I can come up with a modified 'script' that gets everything to work. If it all works out, I'll write a little blog article in case someone wants to do the same thing.



                      • 8. Re: SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final
                        Murray Todd Williams Newbie

                        Thanks, Keith, for that help. I was indeed able to reproduce the example by adding the messageContentIn variable to the overall BPMN service and also adding {messageContentIn, messageContentIn} parameter mappings to the SwitchYard services.


                        As I said before, I'm new to jBPM—I've studied Orchestration when I was getting my SOA Architect certification, but where I'm working we don't already have any SOA architecture (although it's sorely needed) so I'm doing what I can to figure this stuff out in my spare time and to introduce it in "skunkworks project" fashion. So please forgive me as I fumble around a bit as I get my bearings.


                        I do have one question (which I can't seem to find the answer to in the SwitchYard or jBPM documentation) and that is whether messageContentIn is some sort of reserved keyword. I tried a few permutations of using different names for the BPMN variable—I changed the variable definition to "bpmnMessageIn" and then tried setting the SwitchYard service property bindings to {messageContentIn,bpmnMessageIn} or {bpmnMessageIn,bpmnMessageIn} and neither worked.


                        I'm sure I'll figure this stuff out in due time, but if anyone sees where I have misconceptions happening, well... any light you could shed would be appreciated.





                        • 9. Re: SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final
                          David Ward Master

                          Hi Murray,


                          "messageContentIn" is the default name, as is "messageContentOut".  If you want to change this, you can set the messageContentInName and messageContentOutName attributes on the <implementation.bpm> configuration element.  This can be done directly in via XML, or you can set them via the @Process annotation and have the switchyard.xml configured for you.



                          • 10. Re: SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final
                            Murray Todd Williams Newbie

                            Thanks for that, David. This is beginning to make more sense.


                            So I was able to change all instances of "messageContentIn" to (arbitrarily) "bpmMessageIn" both by setting (a) the @Process(messageContentInName="bpmContentIn") attribute on Greeting.java or (b) setting the messageContentInName="bpmContentIn" attribute in the <implementation.bpm> node.


                            At first I thought I had things wrong, because I assumed the messageContentIn="bpmMessageIn" was only setting which BPMN variable would be mapeed for the overall Greeting service, but that the individual SwitchYard nodes would still be expecting the parameter name to be "messageContentIn". So I initial had the parameter mappings down as {messageContentIn,bpmContentIn} for the Hello and Goodbye service nodes. Once I set them to {bpmContentIn,bpmContentIn} things worked again.


                            Anyway, I'll play around a bit more with what I've got working, and I'll stop bothing you guys for a little while. Thanks so much for your help.


                            This stuff is FANTASTIC! ESB/Orchestration has seemed such an unapproachable subject up until now, and SwitchYard is so amazingly clean an "unencumbered" — this feels much the same as when back in 2006 I was untangling a mess of dozens of old-style EntityBeans and discovered the fairly fresh and new "Hibernate" thing that breathed new life into EJBs; or when I discovered JAXB2 annotations and removed thousands of lines of XML processing code from a project.


                            I don't know if I'm being hyperbolic by suggesting SwtichYard might represent the same degree of revolution, but this feels like a really big deal to me. Keep up the great work!

                            • 11. Re: SwitchYard+Forge "Greeting" Demo breaks in 0.3.0.Final
                              Keith Babo Master

                              No bother at all and thanks for the feedback.  Looking forward to getting some more JIRAs from you!  ;-)