rjrudin / slush-marklogic-spring-boot

slush generator for an Angular/Spring Boot/MarkLogic application
Other
10 stars 7 forks source link

Dynamic configurations in xquery resource #53

Open Brian-z opened 7 years ago

Brian-z commented 7 years ago

Hi All,

I created a resource at src/main/ml-modules/ext/resource.xqy.

This resource requires a dynamic setting, depending on which environment I am deploying to. Is there a way to read the application.properties file, and leverage those variables within the xquery resource so that I can properly automate deployments across environments etc?

For instance, I would like to be able to read the mlHost and mlRestPort variables from the application.properties file, at deployment time.

rjrudin commented 7 years ago

The properties in application.properties are available, IIRC, via Spring's Environment API. So within the Spring Boot application, it's straightforward to get the properties.

The next issue is how to send those in a call to MarkLogic. A common approach is to stuff them into HTTP headers, and then access those in code in MarkLogic via xdmp:get-request-header.

Brian-z commented 7 years ago

Hi rjrudin, thanks for the guidance, but Im not sure I understand / expressed my issue properly.

When I run ./mlgradle mldeploy,

I am starting to investigate the ability to have Gradle rewrite the part of the endpoint where the credentials are issued, using the appropriate application.properties file, but am not sure if this is possible/preferable and havent had a chance to dig in yet today.

rjrudin commented 7 years ago

I'm not quite following - at runtime, do you want the xqy endpoint to know the username/password so they can e.g. make xdmp:http-post calls?

Or is this a matter of controlling what username/password are used for deploying the xqy endpoints?

Brian-z commented 7 years ago

The first one, at runtime I want the xqy endpoint to know the usr/pass so they can make xdmp:http-post calls.

I think the rewriter strategy may work but haven't had a chance to test it yet. My idea is to replace the piece of the xdmp:http-post() call that references the username and password with something like !!USERNAME!! and !!PASSWORD!!

Then, from the gradle script, during gradlew build I can have the gradle script open the XQY file, do a REGEX search for the !! values, write the lines to include the mlusername mlpassword variables, do the build, and then rewrite the values back to the !! !! structure

I will let you know if I get the time to test it and how it goes. I've been busy with some other challenges and may get to this over the weekend

rjrudin commented 6 years ago

You could always write a custom task that mlPostDeploy depends on where you use the /v1/eval endpoint of a REST API server - can use port 8000 and connect to your modules database - to fiddle with the contents of any module in your modules database.

Another approach I've used is to have a configuration document, perhaps in your content database, that defines values for connecting to external systems.