We are currently using Orbeon Forms version 4.1.0.201304182144-PE. We have several separate Orbeon Form environments: Local Development, Development Servers, Test Servers and Production Servers. Our Orbeon Forms are initially created in Development and when approved we eventually migrate them onto Production. In order to keep the environments isolated and perform testing each environment has its own HTTP services.
-- We don’t want to modify HTTP service end points in each individual form so we are looking for best practice in order for the form to wire itself to the correct end point. Is the best approach for ourselves to simply define values in Orbeon Properties files on each Orbeon Installation? For example properties file: Server-name = server.name Server-port = 8080 Individual forms would then perform an XPath expression to produce a service end point: server-name + server-port + service-name. This option seems fine however for some services that we consume (although not all services) other teams use different host headers (devl extension for development services etc.) for each environment. Could we use a similar approach to how Orbeon has wild cards for certain properties? So we could do something along the lines all apps and forms have this end point however specific apps or specific apps and forms have this end point. We determined that prod and dev modes could do the same thing however we tend to use just one Orbeon properties file per installation so we don’t really use the modes. Many thanks Graham You received this message because you are subscribed to the Google Groups "Orbeon Forms" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. |
Hello Graham,
we do have some similar issues, different hosts with different scopes (local development, test, production) for the same reason as you do. So we develop our forms manually, pack them into jars an ship them with the wars to the test and production server on several sites. Since we like to have all our customizing in property-files, we can apply the host and port settings of the backend individually. Deployment is easy, just replace the war/jar file and all is fine. In our frontend application, where orbeon is included, we use a FilterServlet which adds the properties to the request attribute and insert them, later while handling xforms-model-construct-done, into the instance which is used to configure the webservice call: i.e. <xf:insert context="instance('serviceConfiguration')/webservice" origin="xxf:element('host', xxf:serialize(xxf:get-request-attribute('webservice.host'), 'text'))"/> <xf:insert context="instance('serviceConfiguration')/webservice" origin="xxf:element('port', xxf:serialize(xxf:get-request-attribute('webservice.port'), 'text'))"/> So, this is our way of handling those issues. It's probably not the best approach but it works fine for us. HTH Regards Heinrich -- You received this message because you are subscribed to the Google Groups "Orbeon Forms" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. |
Administrator
|
In reply to this post by Graham May-2
Hi Graham,
Also, you can use properties for this. See these 2 blog posts: http://blog.orbeon.com/2014/03/storing-configurations-outside-of.html http://blog.orbeon.com/2014/04/configure-url-of-your-services-in.html Alex
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
Free forum by Nabble | Edit this page |