In my upcoming project, I need to integrate a webapp with few other endpoints. Main duty of the webapp will be some kind of thin-client for inner JIRA system for company. Moreover, I’ll need to integrate with SMTP server, some-kind of SMS Api (not known yet) and webservice over SOAP. It should be fast and reliable.
Estimated usage will be around 5 to 15 concurrent JIRA requests (new ticket, edit existing, comment), 10 to 50 people concurrent using Portal (view).
As for JIRA integration, there will be 2 kind of integration:
- scheduled rarely
- scheduled often
- on demand
Scheduled rearely integration will be once a day integration for synchronization of various dictionary values, as well as some customer data kept in JIRA, all persisted in dataabse.
On demand on the other hand, will be when various webapp users will make some JIRA activities through webapp. Some of them are adding new ticket, editing existing, making comments, and persisted in database as “jira cache”.
Scheduled often integration will be once every few minutes synchronization to update various ticket’s data from JIRA to webapp such as current status, comments, progress etc. and synchronization with CRM system to kept up-to-date client list. When new client will be added, there will be addtional synchronization with SMTP and SMS Api, to send email and sms to client. Everything will be persisted in database.
I’ve decided to use Apache Camel for the integration thing as it provides many build-in protocols and awesome Java DSL Api.
I have few concerns/question whether my apporach will be valid and what could be improved:
- I’m thinking about another layer of integration and use ActiveMQ broker within Camel. It should give me more clean way of managing connection then strict integration between two endpoints. But isn’t it to much overhead? It’s another system that may fail and I’m worried about the delay. Did anyone try Camel integration between endpoints with and without ActiveMQ?
- Assuming that I’ll decide to use ActiveMQ, will it be possible to implement easy retry mechanism? Say JIRA is down and I’d like to try send message to it after some time.
- I’m going to persist some infromation before sending them to JIRA, webapp will have most recently “cached” informaction about ticket in database and those data will be shown to webapp user. My concern is whether this may create probles when someone decides to edit ticket in JIRA and in portal concurrent? There’s one special case, when tickets may be edited up to some status. I read that it is possible with some property in JIRA, but I’m not sure if this applies to me (it should be uneditable only for one user)
- Should communication be 100% asynchronous request/response, to give maximum performance? Most questionable thing is whether adding and editing issue should be synchronous with request/response to provide immediately response to webapp user
Thanks for help!
5