Hi Samitha, Great . There are few suggestions. It is good if we have the functionality of updating the process variables configuration from PC to DAS and PC to BPS. Process artifacts will be changed time to time and variables will be changed. And also generated spark scripts should be customizable as analysis of process data will depend on process domain as well.
Thanks, Waruna On Tue, Mar 29, 2016 at 12:25 PM, Samitha Chathuranga <[email protected]> wrote: > Hi All, > > I have started and in the progress of developing Process Variable Analysis > support for WSO2 Process Center. This feature [1] has to be implemented in > collaboration with the three WSO2 products BPS, PC & DAS. So the basic > tasks of the project are, > > 1. From PC, call Admin Services of DAS and create Event Stream and > Event Receiver for the selected process, configuring preferred/selected > process variables. > 2. Communicate DAS configuration information to the BPS from PC, via > REST invocation. > 3. Publish process variable data to the DAS (through the configured > streams and receivers). > 4. In DAS, analyze process variable data and enable drill down > operations on the analytics as requested by the user from PC, view them in > PC. > > Given below is an illustration of the high-level architecture of the > feature. (Also attached herewith [2]) > > [image: Inline image 1] > > > *1. DAS Configuration for process variable analysis, from PC* > > Process owners are enabled to configure which process variables of a > particular process needs to be analyzed from the Process Center's designer > view. Once configured, necessary event stream and event receiver for > selected variables are generated in WSO2 DAS.To create event stream and > receiver in DAS, it has to be up at the same time. This event > stream/receiver creation is implemented via calling Admin Services of WSO2 > DAS. In addition to this, the user preferred analytic dimensions/ drill > down dimensions too are defined and configured and Spark scripts related to > them are generated in the DAS, so they will be utilized for the analytics. > > *2. Communicate DAS configuration information to the BPS from PC* > > Now hence the DAS is configured to receive data on process variables, (for > a particular process) data can be published from BPS where the processes > are actually executed, to the DAS, but BPS doesn't know that DAS > configuration information such as event stream name, event receiver name, > configured variables,etc. So we have to communicate those information from > PC to BPS, after that configuration is completed. For this we will expose a > REST API function in the already existing BPMN REST API in WSO2 BPS. So PC > can invoke it via a REST put call with required authentications. > > *3. Publish process variable data to the DAS* > > So now it is possible to publish process variables from BPS to DAS through > the configured streams and receivers (for that specific process)in DAS. > Already developed BPMN process generic data publisher in BPS can be adapted > for this. Data will be published in certain time intervals. > > > *4. Analyze process variable data in DAS and view them in PC.* > Even though the analysis is implemented in DAS, user doesn't directly > interact with DAS. User interacts with PC to implement analysis operations > via DAS. User will be enabled to specify preferred analysis variables > (y-axis & y-axis) and zero or more drill-down dimensions. For these > drill-down operations, DAS analysis scripts have to be generated at runtime > in DAS, based on the views and drill-down dimensions selected by users. And > analysis results are retrieved to the PC from DAS. So user can view all the > analysis results in graph views which are facilitated with on click drill > down functionalities. > > PC would be included with dashboard features in DAS so the analysis > results are displayed to the user in PC itself in desired views. Following > is a brief clarification on how these drill down analysis is executed. Any > categorical variable available in the event stream can be selected as a > drill-down dimension. For example, consider the following event stream: > > <order id, item id, item type, branch, customer id, > customer address, price> > > One analysis view can be average sales (i.e. average price for across all > events). And there can be two drill-down dimensions: item type and branch. > In the analysis view, average sales will be displayed as a gauge. A user > can click on the gauge, which shows available drill-down dimensions (i.e. > item type and branch). If the user selects branch, analysis view will be > replaced with a bar chart with average sales as the y-axis and branch as > the x-axis (with chart title "Average sales per branch"). Then user can > click on any bar and select the remaining drill-down dimension (i.e. item > type). If the user selected this drill-down for Colombo branch, analysis > view will be replaced with a new bar chart with average sales as the y-axis > and item type as the x-axis with chart title "Average sales per item type - > Branch: Colombo". > > One drill-down dimension can (optionally) be specified as default, in > which case initial gauge view will be replaced with a bar chart with the > default drill-down dimension. > > Process variable configuration and event stream/receiver generation > mentioned in the 1st step are completed up to now. Any thoughts or comments > on the described architecture/ implementation are welcome. > > [1] - https://redmine.wso2.com/issues/5024 > > -- > Samitha Chathuranga > Software Engineer, WSO2 Inc. > lean.enterprise.middleware > Mobile: +94715123761 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, Waruna Lakshitha Jayaweera Software Engineer WSO2 Inc; http://wso2.com phone: +94713255198
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
