Mar
29

Extending the Xcelsius SDK

The Xcelsius SDK as it stands today is a set of core functionality that provides developers with the ability to inject virtually any type of Flex application or component into the Xcelsius designer. The SDK offers a great deal of flexibility and essentially gives developers a blank canvas to start from.

With all of this flexibility available, which is what most developers ultimately want, the SDK can often times be a stumbling block for people trying to get started on custom component development. It never was for me personally, I took a look at some of the examples that came bundled with the SDK and was quickly off and running. However, I think that I picked it up faster because I had a lot of experience in Flex and Xcelsius, so there wasn’t a fundamental gap in my mind as to how all of the pieces fit together.

I think that the gap that causes a lot of developers who are new to the SDK to spend a lot of time up front, is trying to figure out how the entire platform fits together and how their component fits into that picture.  This makes sense, because most developers want to know what’s going on in the grand scheme of things so they can make the right development decisions at the component level.

With the way the current SDK is set up, there’s no really, really clear path for even fairly talented Flex developers (that are unfamiliar with Xcelsius) to jump in and get started without first getting mired down in the technical minutia. Like I said, the SDK offers a great deal of flexibility. It’s the brick, mortar, wood and nails you need to build a house. My thought is; is there a way to repackage the SDK to where all of this flexibility still exists, but at an easier to use level? Instead of wood and nails, could we give people highly configurable frames and still achieve the same ultimate objective?

I think this is definitely possible and have started to spec out a framework that would enable a Flex developer to come into the SDK, drag and drop a few components onto a property sheet, and with absolute minimum customization, facilitate even the most complex of Xcelsius integrations. The goal is to bypass the finer details of boiler plate property sheet operations and integrations and instead focus attention on what matters most – the guts of the actual component and making a great UI for the property sheet.

My parting questions to developers invested in the SDK are:

  1. Do you like how it’s currently structured?
  2. What if anything did you find challenging?
  3. What would make it easier to work with?
  4. What are the top 3 features you’d like to see included?

I’m gathering this feedback for a labs project that I’m working on for the upcoming ASUG event and will be able to share the result with other SDK developers. All input is welcome.

Evan DeLodder is CTO at Centigon Solutions, an SAP Partner focused on the development of cutting edge mapping technologies in the Business Intelligence space. To learn more about him, please visit our Gurus page.

Tags: , , , , , , , , , ,

8 Responses to “Extending the Xcelsius SDK”

  1. Miguel Figueiredo says:

    Hi Evan,

    Great idea and it will clear leverage Xcelsius use broader.

    Some guiding about what we can extend from Flex componente should help, because what we can extend is version dependent
    and limite what we can develop to be used in Xcelsius.

    Cheers, Miguel

  2. Evan DeLodder says:

    Hi Miguel,

    Thanks for your feedback.

    That’s definitely true. Flex versioning does limit what one can extend out-of-the-box, and Xcelsius should be rolling up to a later Flex version soon. Right now we’re all limited to the use of Flex 2.0.1 for Xcelsius 2008 which is needless to say, behind the curve. Regarding extending, are you also talking about the ability to extend the actual Xcelsius components, like the Xcelsius Scorecard or Line Chart for example?

    Thanks,
    Evan

  3. I totally agree with the original post. The main items that really do need to be supported in future release(s) are:

    1) the ability to extend the common set (out of the box) components (both the component and its property sheet)
    2) support for the latest versions of the FLEX SDK.
    3) a better form of debugging whilst in FLEX BUILDER. It is difficult to debug your code and you really don’t know what’s what until you go thru the entire cycle of compiling, wrapping in the XCELSIUS ADD-ON PACKAGER, installing your component, running it, etc.

    I’ve been developing FLEX applications for a couple of years now – I’d love to know what’s on SAP’s future roadmap for this product, and specifically, the XCELSIUS SDK. Right now it’s looking fairly static, untouched.

    Stuart O’Donnell (Consultancy By Kingfisher)

  4. Evan DeLodder says:

    Thanks for the feedback Stuart. Loud and clear on those points!

    It is still the “nuts and bolts”, but getting this type of real-world feedback for SAP from veteran users is a good step and is information that is seriously appreciated by SAP. After getting a distilled list together, I can post a wishlist here and also submit to their idea place. Thanks for participating.

  5. David Moss says:

    Hi Evan,

    Thanks for organizing this effort.

    Some high-level features I find lacking in the SDK are the inability to debug components and not being able to automate the build process (with an Ant script for instance) that would handle both packaging the component and installing it within Xcelsius.

    Some lower level features of the SDK that cause pain points are:

    1) Not being able to use styles in the standard Flex way since they will be overridden

    2) Not having context of the Xcelsius framework at design time. For example, it would be useful to be able to register for events to take action when a custom property sheet is going away – and know if this is because another component in the project is being given focus, or the project is being closed, or Xcelsius is closing.

    3) Not having enough context at runtime. For example, it is non-trivial to determine when all bound properties of a component have been set and it is safe to begin initializing the component. Especially in the case where the component has many properties and some of the properties may be optional or required depending on the state of other properties. Again being able to register a listener for an event when the Xcelsius framework has delivered all the bound properties would simplify the work of the SDK developers.

  6. Evan DeLodder says:

    Hi David,

    Excellent feedback, thanks for the thoughts! Those would be very helpful.

    I’m also thinking of an Xcelsius test harness that could be run from the Flex IDE would be a huge help as well in debugging components. For example, having a very basic test harness that takes in your propery sheet and component MXML files and also includes an Excel grid to simulate both binding and the eventing process that is run through when Xcelsius goes through its various initialization stages.

    -Evan

  7. Stephen Fedder says:

    You can automate the build process, as the current xcelsius packager can be called to build the package quietly with command line parameters:
    \packager.exe filename.xlp -generateXLX
    also the addon manager can be called quietly to install the resulting xlx file in xcelsius with the command:
    \addonmgr_cl.exe -i filename.xlx
    I use this in compiling components from flash builder to automate compilation and installation of the resulting component projects.

  8. Nell says:

    What SAP needs to provide is an Xcelsius (now Dashboard Designer) API so we don’t have to do everything from scratch to create a new component, instead extend an existing one.

Leave a Reply