[
https://issues.apache.org/jira/browse/FINERACT-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger resolved FINERACT-1127.
-----------------------------------------
Resolution: Fixed
> 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
> Components: Reports
> Reporter: Michael Vorburger
> Assignee: Michael Vorburger
> Priority: Major
> Fix For: 1.6.0
>
> Attachments: image-2020-10-09-16-25-14-300.png
>
>
> [~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.20.1#820001)
