Generating schemas and interfaces for LiveView applications
The introduction to LiveView docs explain how to create a new LV project, by first creating the LiveVIew configuration, setting schema and tables, and then creating an EventFlow application to match. I have a pre-existing EventFlow Application, and now I want to create the LiveView component. My .sbapp file contains a QueryTable that I'd like to to visualize in LV desktop. I'm a bit lost as to how to proceed. So far, I've done the following:
1) Create TIBCO LiveVew configuration file
- Choose application, as opposed to Data Table
What are the remaining required steps?
PS, this is my first time posting and this community interface is awesome.
(4) Answers
In general, StreamBase Query Table Delta Stream features are documented here. Or if that link doesn't work someday, try here.
One key detail I'd like to call out to you is that if your Query Table is a shared table, you have to create the delta stream off the shared instance of the table and not a placeholder declaration of the table. If you don't have shared query tables, just ignore what I just said. You should probably mention what versions of StreamBase and Live Datamart you are using; it'll save me time having to qualify things that have changed between versions.
Thanks. You're right, I just want to view the query table that's already running in my .sbapp. Since I'm only doing this for testing purposes, I am fine with the default messaging/topolgy infrastructure. How do I define the Delta Stream, as you mentioned? Also, I noticed right clicking on my project and choosing streambase gives the options to "Generate LiveView Interfaces, Generate LiveView Schema". Are this what I want?
Since 2.0 of LiveView, er, TIBCO Live Datamart, there is way to import a StreamBase named schema from an .sbapp or .sbint file and use that as the field schema for a Live Datamart data table. And starting with 2.0.2, the LVconf editor provides a nice little UI for this feature.
So that's probably the best way to keep your StreamBase Query Table and LiveView data table definitions in sync, especially where the Query Table existed first.
If your schema definitions exist in a different project from your LiveView project, then the location of the sbapp or sbint has to be added to the module search path of the LiveView project in order for the import to resolve.
There will be some niggling little application packaging issues if you don't want to keep multiple copies of the "same" file with the schema definition in multiple source projects around and in sync. Not all of these are super-resolved with ease by the products as they exist today, so that's going to be worth thinking through.
Now we have to talk about how to get the data from the Query Table into the Live Datamart table at runtime. The mechanism for doing this depends on whether the source Query Table is running in process with the Live Datamart server or not.
If what you want to do with Live Datamart is visualize from some already running StreamBase application, which from your question is what it sounds like you are doing so I'll assume that for the rest of this reponse, then one way to do it is to define a Delta Stream for your Query Table, and send the output from the Delta Stream to a LiveView Publish adapter aimed at the Live Datamart server, after suitably Mapping the Delta Stream's output into a schema the publish adapter wants (not that hard) but taking care to make sure that deletes from the Query Table are sent as delete operations to the publish adapter and not insert/updates.
Depending on the messaging infrastructure and topology at your site it may make much more sense to use some other kind of messaging system to publish out of StreamBase and into Live Datamart. In that case you would use an output adapter for the messaging bus rather than a LiveView Publish adapter, and use an messaging input adapter in the Live Datamart process somewhere, as part of either an embedded publisher or an application data source into the data table.
There, that's the high level sketch. Obviously a lot of little detail steps elided there, but you probably have some decisions to make (or learn about the way your site already does such things) in how the communication is going to happen between servers before it's worth getting super-specific.
Phew! That's a lot of stuff. We can break it down further as we go if things aren't obvious, and some things probably won't be.