WSO2 Internship - VI

In this series of posts, I provide some key points and Ideas that I report to my university during my internship. I arrange these posts as a set of reports, where each report provides the summary of tasks I have done during those four weeks of my training and the experience I gained during that period.

This post is the final post in the series of posts about my internship @WSO2.

This report was nearly the end of my internship since our company has annual leave starting from 23rd December 2016 for Christmas and New Year; We had only two out of three weeks to complete our overall internship.

For my project, I have nearly completed the project, So I had code reviews based on two code reviews I have corrected and further completed the progress on my project.

Code Review - 1 Notes

1. Sort the records which belong to the same activity id. Thus when we are doing a search based on activity id, we will get lots of data, but that should be in the order they received, not in improper order, then only it will be easy to understand by the user.
2. Make an alert by checking the count in the grid instead of distance calculating with the window.
3. Change the execution plan of wait time alerts to remove the matched entries, using every.
4. Move the search messages button to the bottom of the page, also the add attribute, clear all buttons.
5. Program should select max entries with a fixed drop-down box (1000, 10000, all. etc. records)
6. Meaning of the acronyms - ADT, ORU, ORM., etc.
7. The graph should be on the correct axis for the line chart.

I correct the 3,4,5,6,7 as instructed since these are minor errors compared to the first and second.

I modified the execution plan for 2, but it does not exactly make sense to the real case scenario. I count the number of disease occurrences based on the integer value of latitude longitude boundary, but that should be meaningful to make it efficient.

The first one is not much important, and since I had another review the next day, I could not complete the correction before the second code review.

Code Review - 2 Notes

The execution plan for disease Alerting

1. Use meaningful names for stream names
2. Remove grouping by the city
3. Analyze the description of the disease and then come up with the disease(s) (probably using Natural Language Processing (NLP))
4. Refactor and refine the block allocation mechanism (removing the 0.5 and using a proper roundup method)
5. Add a snapshot saving mechanism to the disease count window

I have corrected (1) and (2), and (3) one is maybe look at in the improvement state since the current time is not enough to analyze. (4) I adjusted a little bit but a bit more to improve in it. (5) can be done by configuring <SERVER_HOME>/repository/conf/eventprocessor.xml file

Spark script

1. Remove unnecessary, redundant tables.

I tried to remove the redundant tables, but I keep them but remove redundant fields like subtype in all analyses due to lack of time. Also, format the code to be in a single style.

Dashboard

1. Allow the user to edit the Lucene query on the search page
2. Have a way to format the HL7 message on the search page

I have done 1st part to work fine, and two was said to be the improvement in the feature release.

Event Publisher

1. Update the HL7 transport code to handle the message direction

This part should be merged/reanalysis again to fix some issues; then, only message direction will work fine.

Finally, overall I had an excellent Internship and gained the following technical knowledge.

• Creating OSGi component
• Designing Dashboards
• Working with JQuery and Some JavaScript Library
• Spark and Siddhi