Skip to content
This repository has been archived by the owner on Aug 9, 2022. It is now read-only.

Dynamic configurations in xquery resource #53

Open
Brian-z opened this issue Oct 10, 2017 · 5 comments
Open

Dynamic configurations in xquery resource #53

Brian-z opened this issue Oct 10, 2017 · 5 comments

Comments

@Brian-z
Copy link

Brian-z commented Oct 10, 2017

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
Copy link
Owner

rjrudin commented Oct 10, 2017

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
Copy link
Author

Brian-z commented Oct 10, 2017

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

  • The Spring side of things is fine, I can access those variables. (WebApp configuration)

  • the Mark Logic Resource of things does not have access to those variables. (Mark Logic Endpoint Configuration)

  • when I run ./gradlew build, everything works fine, the webapp is built with all the approproate environment variables.
    - I added a -Penv=[environment] to the call to direct gradle with application.properties to load for Spring.

When I run ./mlgradle mldeploy,
- This deploys the xqy endpoints

  • within those xqy endpoints I would like to access the username and password, similary to how the Java Spring App is built with the proper credentials.

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
Copy link
Owner

rjrudin commented Oct 13, 2017

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
Copy link
Author

Brian-z commented Oct 13, 2017

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
Copy link
Owner

rjrudin commented Oct 18, 2017

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants