Topic
9 replies Latest Post - ‏2014-06-10T07:43:51Z by TrushkinAndrey
Mahesh@123
Mahesh@123
3 Posts
ACCEPTED ANSWER

Pinned topic Fanout Primitive issue in IBM WESB v7.5

‏2012-08-20T15:24:21Z |
In IBM WESB v7.5, FanOut primitive in the iteration mode using XPath expression is always giving me last element in the array. How can I fire each element in the array?
Updated on 2012-12-11T09:08:02Z at 2012-12-11T09:08:02Z by mmalc
  • mmalc
    mmalc
    74 Posts
    ACCEPTED ANSWER

    Re: Fanout Primitive issue in IBM WESB v7.5

    ‏2012-10-07T09:13:15Z  in response to Mahesh@123
    Maybe you haven't specified something correctly as it works for me.

    What are you doing in the fan-out section? What clause do you have on the fan-in to end the loop?
    • mmalc
      mmalc
      74 Posts
      ACCEPTED ANSWER

      Re: Fanout Primitive issue in IBM WESB v7.5

      ‏2012-10-07T09:17:27Z  in response to mmalc
      Have a look at the samples in particular the "Aggregation by iteration" sample in the "Mediation features" section.
  • SystemAdmin
    SystemAdmin
    289 Posts
    ACCEPTED ANSWER

    Re: Fanout Primitive issue in IBM WESB v7.5

    ‏2012-10-26T22:21:37Z  in response to Mahesh@123
    This is a bug of BO maps. BO maps between FanOut-FanIn have it the FanIn context always the same value. Use the XSLT maps here instead, they work fine. (We use BO maps everywhere, but between FanOut-FanIn we use XSLT maps, because of this bug.)
    • mmalc
      mmalc
      74 Posts
      ACCEPTED ANSWER

      Re: Fanout Primitive issue in IBM WESB v7.5

      ‏2012-10-28T04:02:52Z  in response to SystemAdmin
      If using a BO Map is an issue in your Fan-Out flow then I'd raise a PMR rather than using an XSLT primitive. Each use of an XSLT primitive requires a serialize/deserialize from BO -> XML. OK if you have small payloads and low volumes but if you want to scale it up then every little bit adds on.

      The XSLT primitive is faster if you're transforming a request as soon as it gets into the flow, makes use of the deferred parsing mechanism. But if you're already in BO land then the BOMap is faster.
      • SystemAdmin
        SystemAdmin
        289 Posts
        ACCEPTED ANSWER

        Re: Fanout Primitive issue in IBM WESB v7.5

        ‏2012-10-28T20:05:56Z  in response to mmalc
        You're right, XSLT maps are slower (though I didn't know that there are situations when XSLT maps are faster). We've already submitted the PMR for this bug, I think. But:

        1. We have bad experience with IBM support, it takes a big effort to persuade them that there's a bug in their product. Even when we told them "you have this bug at this particular line of code in this particular class", they didn't act and fix that error. :-((

        2. WESB and IID are full of bugs. A fortnight or so ago I was asked to write down a list of bugs and problems we've met during the WESB development. I was able to put down about 50 of the more serious bugs (of the version 7.5), just by heart. And there is a lot more bugs I didn't recall at that time, and another lots of less serious bugs and problems. It would take a whole week to create a PMR for every of these bugs (with all the necessary details), and at least a month to persuade IBM to fix them. At that time our project would be over.

        Seriously and without exaggerating, WESB and IID is the most buggy development platform I've had to develop for. The idea is good, but the implementation is terrible. I would say they never tested it at IBM before releasing it. Shame on IBM.
        • mmalc
          mmalc
          74 Posts
          ACCEPTED ANSWER

          Re: Fanout Primitive issue in IBM WESB v7.5

          ‏2012-12-11T09:08:02Z  in response to SystemAdmin
          Just like there are best practices in building applications, there are unfortunately best practices for raising PMRs. In my line I come across a lot of people that have struggled with the PMR process and often we come in and help get the problem resolved reasonably quickly. For your information this is what I do when I have a re-creatable problem.

          1. Isolate the problem to the smallest possible set of components. Preferably without having to introduce your own systems in to the mix. For WID/IID, this is usually easy.
          2. Document in any document editor of your choosing, the steps needed to re-create the problem. This includes screenshots and itemised steps. This sounds like a lot but you need to do this anyway to prove to yourself that the problem is actualy with the product.
          3. When running the test, ensure the logs are empty before you start (or note the timestamp in the log files that you started/ended the test). (it's amazing that people think that sending multiple 50MB log files to someone to process with no pointers as to where to look will get the problem resolved faster)
          4. Gather the necessary files for the MustGather. (unfortunately this is just part of the process)
          5. Raise the PMR and send all the necessary info you've just collected. This will get you past Level 1 and give level 2 something to try immediately. If they are able to recreate your problem then it goes straight to Level 3 for resolution.

          It works for me and maybe next time it may work for you.
          • LaxmiG
            LaxmiG
            3 Posts
            ACCEPTED ANSWER

            Re: Fanout Primitive issue in IBM WESB v7.5

            ‏2014-06-03T11:48:42Z  in response to mmalc

            Try to change the parsing mode of the business objects to Eager parsing, if you are using Laser parsing. I tried this and it worked

            • SRIMORI
              SRIMORI
              20 Posts
              ACCEPTED ANSWER

              Re: Fanout Primitive issue in IBM WESB v7.5

              ‏2014-06-10T07:39:02Z  in response to LaxmiG

              Hi,

              In IBM WESB v7.5,  lazy parsing mode  is default and it is faster and performent than Eager parsing, but how does it works by simply changing  the parsing mode from lazy to eager.

              then we can come to conclusion saying that when ever we have fanin-fanout we should use only Eager parsing mode?

              Can anybody help me to provide answer for my question.

              Thanks,

              SriEAI

              • TrushkinAndrey
                TrushkinAndrey
                111 Posts
                ACCEPTED ANSWER

                Re: Fanout Primitive issue in IBM WESB v7.5

                ‏2014-06-10T07:43:51Z  in response to SRIMORI

                Hi.

                 

                Lazy mode is default. And in many cases it is much faster than eager.

                In many projects I used FanOut and FanIn primitives with lazy mode. WebSphere bug is observed only in Eager mode.