Functionality added : conformance level description

[Thomas Sødring]

On 12/01/2016 09:01 PM, Petter Reinholdtsen wrote:
>
> Hi.
>
> [Thomas Sødring]
>> Folks,
>>
>> I'm back developing as I have had a few days between the end of the
>> teaching semester and exam correction time. I thought I'd prioritise
>> what Petter was asking for and that is the top level description of
>> functionality the core supports and where the associated apis are
>> located.
>
> Very good to hear you are working on the features.  I gave the current
> git version a go.  Btw, will this change bring us closer to adding
> postjournal data into the database?  I am eager to test the store and
> search functionallity. :)

In a way it does bring us closer in that I have had to look at building
HATEOAS resources. I ended up creating my own serializer
(ApplicationDetailsSerializer.java) to handle this for the application
detail, but I am not sure that I will use this approach for the other
objects. I am currently looking at using the standard spring HATEOAS
mechanism.

But I think what I can do to move things along is to implement caseFile
(saksmappe) and registryEntry (journalpost) next. I was going to start
at fonds (arkiv) and work my way down, but I don't think I really have
to do it in that order. So I'll try and have this functionality in about
2 weeks.

>
>
> Anyway, both 'mvn -Dmaven.test.skip=true clean install' and '(cd
> core-webapp; mvn spring-boot:run)' and work.  And I get the json output
> when asking Chromium to visit the <URL: http://127.0.0.1:8092/noark5v4 >
> URL after logging in.

OK! But you shouldn't have to log in to retrieve anything from the
context path. I'll double check that but I think the api conformity
descriptions should be available without logging in. I'm hoping you're
getting content type *application/vnd.noark5-v4+json* and not
*application/json*

>
>> The first two are the official Noark 5 api interfaces that we must
>> support, the final two are my own apis that I want to support. We will
>> probably see a few more official api descriptions in the future.
>> byggesak and masseimport are two that I think will be on the horison
>> soon.
>
> I see the use of a bulk import API, but why can't byggesak use the
> normal saksarkiv API?

First I have to say that I think the standard is woefully under
described. I was also not part of the committee that developed it so I
have no definitive answer as to why there are 2 apis (arkivstruktur and
sakarkiv). But I can reason that the arkivstruktur api is related to
common functionality, while sakarkiv is a specific subset of
functionality that has been pulled out to it's own api, representing the
domain of case-handling. Any case handling system will use both apis. So
byggesak will be its own "domain" like sakarkiv is. It will have its own
metadata. It might be that byggesak will extend sakarkiv, but that
remains to be seen.

You can trace this thinking back to the evolution of Noark from Noark 4
to Noark 5. Noark 4 was very much sak/arkiv and you see this in the
metadata. It meant that the standard precluded other metadata domains
(e.g. byggesak) from being included in the system. Noark 5 opens up for
a lot more flexibility and easier includes other metadata domains. A lot
of people, including me, believe that we need to separate arkiv from
sak/arkiv and let sak be a specialised system (no:fagsystem) on top of
arkiv. We can see this approach in the api and hopefully we will see new
domains being introduced over time.
>
>> Please note that going forward you must specify that you only accept
>> application/vnd.noark5-v4+json on the client.
>
> OK.  Is this the case already?  I did not expect Chromium to do this
> automatically, but it seem to work to get the json output for the
> toplevel URL.  But when I visit the individual pages (all four, looking
> like <URL: http://localhost:8092/noark5v4/hateoas-api/arkivstruktur >),
> I get this:
>
>   Whitelabel Error Page
>
>   This application has no explicit mapping for /error, so you are seeing
>   this as a fallback.
>
>   Thu Dec 01 19:58:03 UTC 2016
>   There was an unexpected error (type=Not Found, status=404).
>   No message available
>
> Am I doing it wrong?

No, you are not doing anything wrong! I only introduced
application/vnd.noark5-v4+json at the top level. Going forward I will
replace application/json with application/vnd.noark5-v4+json. I learnt
once that updates should be very specific and that I should avoid
putting many different updates in a single commit.

An interesting question is what should be at
http://localhost:8092/noark5v4/hateoas-api/arkivstruktur? Does the
standard even say that? I don't think the standard has anything there.
The self-exploratory nature of HATEOAS suggests that it probably should
give you a list of what you can do given the role/user that is logged
on. So if you are record manager (arkivleder) you will see things like
fonds (arkiv), but if you are a case handler (saksbehandler) you will
see your case files.

So you should be going to
http://localhost:8092/noark5v4/hateoas-api/arkivstruktur/arkiv instead.

Another potential reply here could be to identify which of the optional
requirements we have implemented. But to be honest, I don't know what
should be there and you are currently seeing a "nice" error message.
This should really be replaced with a 404. I think this is basically the
gui api creeping into the other apis. The gui api has the ability to map
404 to a nice error page /error, but there is nothing at /error.

So I'll start working on case handling and registrations and try and
push them asap. It should be relatively quick to get the required
functionality up and running, and add the business logic later. But your
use-case is really to do a mass import. createdDate etc will be set to
creation time (now) when it's imported to the core and that will mess up
the search functionality. So maybe we should introduce the third non
official api, import so that you have something to play with. The import
api will be relatively simple to implement.

 - Tom