Re: Apache Fineract CN API Documentation
In order to help you, I will need to understand what you are actually
trying to do. I skimmed the section of your document that you named,
but I don't have time to read a 190 page document.
I suspect you are trying to write a REST service which would connect
Fineract CN and mojaloop.
* Is your question whether a service can be written with the
properties you've listed? If that is your question, the answer is
"yes". In particular, the client does set financial transaction
identifiers (though it's not clear from that part of the document that
financial transaction ids is what is being refered to there.)
* Is your question whether one of the services in Fineract CN has
those properties? If that is your question, then the answer is "not
fully". In particular, Fineract CN transmits information about
completed work via ActiveMQ and not per REST callbacks.
I think the usefulness of discussing this in the abstract is limited.
If you want to get this working, you'll need to find someone to
program it, or do it yourself. If you don't yet have these skills,
you can learn them. If you want someone else to do it, you'll
probably need to pay them. If you or someone else does decide to work
on it and to do it as open source, I'll be glad to provide moral and
technical support, within certain limits.
On Fri, May 25, 2018 at 11:42 PM, James Dailey <jamespdailey@xxxxxxxxx> wrote:
> Isaac - This is a thread I am trying to follow. Thank you for all the work
> you're putting in, and to Myrle for being a mentor on this work. Seems
> like it is leading to something really important for the project.
> I wonder if this <
> should or could be expanded to explain and document the API or if we should
> have a separate API Documentation File.
> At a requirements level, I'm trying to figure out how Mojaloop APIs and
> Fineract-CN APIs would interact, perhaps as a model for how Fineract-CN and
> other outside API driven systems will function together. On the Mojaloop
> project they have a 190 page documentation of the standard API starting
> with some statements that I think may also be relevant to how the
> Fineract-CN services architecture is set up.
> Specifically, I'm referring to section 3.1.1. . Of those characteristics
> mentioned, which apply to Fineract-CN? :
> - Fully Asychronous (esp for long running processes) : my guess, seems
> likely yes on Fineract-CN - yes?
> - Decentralized (no central authority): My current understanding is
> that Fineract-CN has dependencies but not centralization?
> - Service Oriented : that seems like a given in Fineract-CN as it is
> also a micro-services arch.
> - Not fully stateless (some info required to be kept client and server
> side to complete fin tranx): Hmm...
> - Client (side) decided common ID (complexity reduced by relying on
> client to initiate tranx calls): Maybe not yet in our thinking ? contrary?
> Similarly, there is a reference to how generic URI's are formed with a
> given example:
> and other things like max header size and so forth.
> As I lack the skills to actually work on this code, I'm hoping I can
> contribute at the level of conceptual understanding and requirements, and
> perhaps add to the Documentation if I can understand what is actually going
> on here. If this is already documented, please send me there.
> ( Myrle - hope this is helpful, if not, let me know please. )
> - James
> On Thu, May 24, 2018 at 6:00 AM Isaac Kamga <isaac.kamga@xxxxxxxxx> wrote:
>> Hello Myrle,
>> Trust that you're doing great.
>> Following your recommendations, I intended solving the issue using a 3-step
>> 1. Obtain token
>> 2. Validate token
>> 3. Add token to MockMvc call as a header.
>> However, I've been unable to get status different from 404 (Not Found) and
>> 403 (Forbidden) in the MockMvc calls...so I think I'm getting at least one
>> of the 3 steps above wrong.
>> Regarding 1.), I used TenantApplicationSecurityTestRule's
>> getPermissionToken() method to obtain some tokens based on Allowed
>> operations (Read, Change and Delete) and they were each of the form
>> eyJhbGciOiJSU....*". Which service actually generates tokens ?
>> in anubis ?
>> Concerning 2.), The tokens I obtained failed the
>> SystemSecurityEnvironment's isValidToken() method. So how can we validate
>> the obtained tokens ?
>> Regarding 3.), I noticed that Spring MVC Test provides an interface called
>> the RequestPostProcessor
>> can be used to modify a request. I intend to use this to add a valid token
>> to each MockMvc call. I wrote a method which modifies a request by
>> adding a *header(ApiConstants.AUTHORIZATON_HEADER,
>> myToken)* and then running each MockMvc call in the unit test with an
>> object of the class holding this method.
>> Also, you mentioned a Spring Security filter which filters requests to
>> endpoints. Where exactly is this filter located ? I've been scouring anubis
>> for it to no avail. I'm considering mocking the filter to permit specific
>> tokens or calls go through.
>> Your help will be greatly appreciated.
>> At Your Service,
>> Isaac Kamga.
>> On Tue, May 1, 2018 at 11:41 AM, Myrle Krantz <myrle@xxxxxxxxxx> wrote:
>> > Hey Isaac,
>> > On Tue, May 1, 2018 at 11:17 AM, Isaac Kamga <isaac.kamga@xxxxxxxxx>
>> > wrote:
>> > > Thanks for your very helpful feedback.
>> > You're very welcome. Thank you for taking it so well.
>> > > Do we have to use a different approach ( possibly the documentation
>> > module
>> > > you earlier proposed ) for asynchronous calls (POST, PUT, DELETE ) from
>> > > synchronous ones (GET) ? This can be done later but I wanted to know
>> > > thoughts on this.
>> > Fortunately we do not. The asynchronous calls will return an
>> > ACCEPTED, and the synchronous calls will return OK. From the point of
>> > view of the documentation, and of calling them, that's the only
>> > difference. The asynchronous calls can also return BAD REQUEST for
>> > any invalid values which are fast to check (where the synchronous ones
>> > will return BAD REQUEST for invalid values regardless of how easy they
>> > are to check.)
>> > The documentation module is still an open question for me. But not
>> > because of asynchronous vs synchronous calls.
>> > > Thanks for shedding more light on how this works. When I saw how "easy"
>> > it
>> > > was to do API calls, I asked myself how one could get to intercept
>> > > information such as the status of a response. Building a new test
>> > > that works with mockmvc can be a daunting task. I hope I can count on
>> > your
>> > > help when I run into frustrations.
>> > I'll do what I can, but I don't know mockmvc. I've never used it,
>> > partly because of this problem.
>> > > So far, I created this document
>> > > <https://cwiki.apache.org/confluence/display/FINERACT/Apache
>> > +Fineract+CN+API+Documentation>
>> > > to
>> > > help developers generate the asciidoc files themselves from the unit
>> > tests.
>> > > Would you prefer that we put this in the repository's README file or
>> > leave
>> > > it on confluence ?
>> > Let's start off with it where it is, and see whether it works by
>> > trying it out there.
>> > You're doing good,
>> > Best Regards,
>> > Myrle