lsc
lsc copied to clipboard
creating a web service plugin for lsc
Hello @coudot @soisik,
we are currently thinking about using lsc for his transformation engine and synchronisation aspect in complex workflow.
The scenario is like this :
- getting the data from a application through is webservice to lsc
- applying transformation to it if nedeed
- sending back the data to another webservice from lsc to provision this data
The use case if for example :
- Application A is a student management system with all the data about the life cycle of students
- Application B is FusionDirectory and is REST webservice
- LSc with a webservice plugin is used to get data from A and send it to B following the task programmed
do you think its feasible and useful, we would like to have it made in a generic way and contributed back to the project of course
Hello,
This is very interesting and I'm thinking about this for some time.
The main issue is how can you configure in a usable way a generic REST LSC service? As far as I know, the following elements need to be parametrized:
- method (GET/POST/PUT/etc.)
- URL (with some parameters in it where you can put a pivot or some other attribute)
- mapping between the json and a list of attributes
- authentication mechanism
And I don't speak about specific API which can require you to create a batch before doing any request.
Here are some sample plugins I created to access some REST API:
- https://github.com/lsc-project/lsc-obm-plugin
- https://github.com/lsc-project/lsc-openpaas-plugin
- https://github.com/lsc-project/lsc-james-plugin
I really hardly see a way to define the plugins in a common way, even if I would really be happy to!
Hello,
This is very interesting and I'm thinking about this for some time.
The main issue is how can you configure in a usable way a generic REST LSC service? As far as I know, the following elements need to be parametrized:
* method (GET/POST/PUT/etc.) * URL (with some parameters in it where you can put a pivot or some other attribute) * mapping between the json and a list of attributes * authentication mechanism
And I don't speak about specific API which can require you to create a batch before doing any request.
Here are some sample plugins I created to access some REST API:
* https://github.com/lsc-project/lsc-obm-plugin * https://github.com/lsc-project/lsc-openpaas-plugin * https://github.com/lsc-project/lsc-james-plugin
I really hardly see a way to define the plugins in a common way, even if I would really be happy to!
thanks for the quick response .
What we now for sure is that we will need a plugin for FusionDirectory https://rest.fusiondirectory.org/
yes i don't know how its still an open question :)
Maybe provide a skeleton to create more easily webservice plugins or provide a way to read the configuration from a yaml file if they respect the https://www.openapis.org/ standard.
i perfectly understand that all of this is a big vague right now and opened this bug for discussion
Hi,
openpapi is very interesting and a step in the good direction.
Looking at your REST api, it seems that to be able to access some object, you first need to authenticate. Which means discovering the authentication endpoint, knowing that you must get a token from it and finally use this token in every (other) calls.
How could we describe this in a configurable way?
Regards, Raphaël.
@rouazana The openapi file specifies the following:
securitySchemes:
session:
type: apiKey
name: Session-Token
in: header
Which tells you there is an authentication method called session, which is a key sent as a header with name Session-Token.
Then you have:
security:
- session: []
Which means all methods need the authentication method "session" unless stated otherwise.
And for a few methods like login, you have:
security: []
Which indicates these ones do not need authentication.
So for a generic plugin, you could from the openapi file know which kind of authentication is expected and which methods needs it. You will still need in the configuration the way to actually login (which endpoint, with which parameters).
Interesting, thanks.
An other point of attention is pagination. It seems to be handled in very different ways in different APIs. For example some of them rely on the offset / limit parameters, while others apply a default pagination and return the next page in the response.
Hi,
I've created a plugin to synchronize entities from and to fusiondirectory using the REST API that will be available in Fusiondirectory 4: https://github.com/Worteks/lsc-fusiondirectory-plugin
This feature request was about a generic openapi REST plugin but Fusiondirectory REST services being quite specific (for example attributes are read/write within tabs), I don't see how it could be made generic.
I'm waiting for the approval from dev team to make it available in LSC repository.
Regards
hello @soisik,
that great news, looking forward to test and use it
Cheers