Michael Vorburger created FINERACT-1127:
-------------------------------------------
Summary: Modularize Fineract to allow something like e.g. the
Pentaho integration to be built and run separately
Key: FINERACT-1127
URL: https://issues.apache.org/jira/browse/FINERACT-1127
Project: Apache Fineract
Issue Type: New Feature
Reporter: Michael Vorburger
[~francisguchie] thanks for raising
[https://github.com/apache/fineract/pull/1262/files] for FINERACT-1094, even
though we cannot merge it due to licensing, it helps at least me to see it
nicely isolated like that, e.g. for this discussion!
Seeing that, and subsequent FINERACT-1125, led me to wonder if an alternative
future architecture approach here could be to have a 3rd-party, such as the
Mifos Initiative, offer Pentaho integration for Fineract not anymore by forking
Fineract and adding code to it (which is always a PITA to maintain, in the long
run), but by building and releasing an entirely separate runnable binary
artifact (WAR / JAR) for it... this could be very neat even from a runtime
perspective - completely separate REST API, and (possibly "heavy"?) report
generation?
_One could even image breaking out running scheduler jobs separately from API
serving. Ultimately, this could effectively be the start of breaking Fineract
1.x into a CN-like "microservices" deployment... but I'd envision that to,
always, just be one option, a possible alternative - with the current WAR/JAR
remaining as is, forever - but it would just "assemble modules" for the
"monolithic deployment distribution". Anything along these ideas is further
down the line, but starting with making this possible for reporting could be a
pragmatic start.... let's focus on that only, in this issue._
This is more of a still somewhat vague idea at this stage. The next step would
consist of spending more time understanding the details of how Fineract's
{{ReportingProcessService}} is designed... I personally don't know that much
about it, but looking at PR #1162, one can kind of gather that this
{{PentahoReportingProcessServiceImpl}} needs to implement
{{ReportingProcessService}}? What would it take for the front-end to be able to
call another service (or Fineract to HTTP redirect reports to an external
service...), and then for such an external service to be able to... do exactly
what, actually - what's the lowest common denominator integration touch point,
here? From an only very quick glance at the code, it looks like we're basically
"passing through" JDBC connection details? So... what one would need is to be
able to build an external Fineract (non-CN) service that can access the same
DB? Sharing a minimal amount of {{fineract.infrastructure.core}} code, as a
library...
[~francisguchie], [~ptuomola], [~awasum], [~xurror], [~edcable] FYI.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
