|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (26)
View page history... |
| h3. Source code |
| Source code for example this is [here|http://mediacast.sun.com/users/Serge_Blais/media/iepCrossDBUpdates|Source [here|http://mediacast.sun.com/users/Serge_Blais/media/StockSampleSource|Source code of this sample] as a zip file. You can also connect to the kenai project, the svn for this sample will be [here|http://kenai.com/svn/iep-workshop~sample-1/|svn repository]. |
h3. How to... |
| The video of how to build and test this project is here. |
| The video of how to build and test this project is [here|http://mediacast.sun.com/users/Serge_Blais/media/iepStockTradingMovie|Wink movie of the application construction]. |
h3. Technical Complexity |
... |
| h3. Purpose |
| * Monitor a stream. In this example, exercise, we are keeping 3 levels of data: |
| *# The last day of data *# The last 3 entries for a specific key |
... |
| h3. Situation |
| * In the stock market, The last transactions provide valuable information to day trading. This model updates the internal db table, so that only the last stock transactions are transaction per market is kept in the table, minimizing its table. This minimizes the table size and providing a higher throughput. To see the sample on how to send the data to an external db, please see [here|JavaCAPS:Cross DB Relational Updates|Updating external DBs] . |
| * Basic Stream calculations |
... |
| h3. IEP Constructs Used !iepStockProcess.PNG! |
| h3. IEP Constructs Used |
| h4. Process Flow |
| # The events are acquired through the input. # From there, a one day table is kept in the inbound section of the process. # Using the last rolling 24 hours, an aggregation is done on the data to obtain the count of transactions and the sum of the money transferred for a symbol/market. # From that table, we keep only the last value for the symbol/market doublet key. # This result is kept into the table output. |
| h4. Process Flow |
| h5. Elements |
| * Inbound stream |
* Stream Input |
| * Partitioned Window |
| * Relation Aggregator |
| * Relational Updates |
| * Table Output |
| h4. |
| h4. Stream Input |
| Here we define the data, as we will consume it. !StreamInput.PNG! |
h4. Relation Aggregator This is the SQL statement used to aggregate the data we need. !RelationAggregation.PNG! |
| h4. Partitioned Window |
| This is the window we keep for presenting the derived event to our client layer. As you can see, we're keeping the same aggregation/partitioning (symbol/market) as in the aggregation operator. !PartitionWindowEditor.PNG! |
| We can see in this operator that we've set to keep the last 3 elements of the stream, for each stock. So this way, we have a shallow history on each element important for us. |
| h2. |
| h3. |
| h4. Table Output |
| In this operator, we define how the data will be presented to the outside world, in a "known" table. Making it global allow us to keep the data even if the iep process is being undeployed. !TableOutput.PNG! |
| h3. Example Limitations |
| * Unknown |