8 Replies Latest reply on Dec 23, 2011 11:21 AM by Kevin Cavallo

    Cross Environment Deployment

    vozeldr Level 1

      Enterprise Cafe seems to have eaten my original post twice, but if it does show up sorry for the duplicate.

       

      Before I go into detail and background, my primary question is: From an XDP form hosted in LiveCycle (rendered as PDF) how can I determine what LiveCycle server is hosting the form?

       

      In April we migrated from LiveCycle 7.2.2 to LiveCycle ES 2.5. With LiveCycle 7.2.2 we would deploy our "applications" by exporting the individual processes and storing them in source control along with the schemas and XDP forms. We were then able to just do a find and replace to change the URIs for the web service calls used in all of the processes and forms at once for deployment from dev to test and again to production. With LiveCycle ES 2.5, we store the exported LCA files in source control and then after deployment to whatever environment have to go into workbench and change all of the URIs. I suppose we could extract the LCA and do the find/replace but we haven't tried that because we don't know the exact makup and layout of the LCA and don't want to risk corruption.

       

      My idea was to somehow determine what LiveCycle server is hosting the form when it initializes to start a new process, thus determining if it was running on dev, test or production. I could then set a hidden form field to the value of the web service URI for the environment. After that every time the form loads throughout the workflow, I would need to go through all of the xfa.dataSet connections and set the value of the soapAddress (I'm assuming this will work but haven't yet tested it). In the processes, I could pull the value of the form field with an xpath expression and set the target URL for the web service operations.

       

      If anyone reads this and has encountered and overcome the same problem I would love to hear how. I would like to make sure that I get the best possible architecture, but with the least amount of effort since we only maintain these LiveCycle applications and for now no longer actively develop them.

        • 1. Re: Cross Environment Deployment
          vozeldr Level 1

          As a side question, our forms generally use about 5-10 calls to different operations on a single web service. They are implemented in LiveCycle Designer as different connections for each operation, even though they are on the same web service. Is that appropriate or how something changed that would allow them to be a single connection with multiple operations, each operation still having binding capabilities to form fields for request and response capabilities? It looks like the model for the connection set would allow that but that designer doesn't.

          • 2. Re: Cross Environment Deployment
            Kevin Cavallo Level 4

            I haven't worked much with calling web services from forms so I can't help with an elegant solution.  Your idea seems sound.  I can help with two ways of obtaining the LiveCycle server:

             

            1. You can use a process variable that is defined as a Configuration Parameter.  The value of configuration parameters for a process can be set in the Admin UI; you would set the appropriate value on each server after deployment.

             

            2. Use a Script Action with some java code that obtains the current server name.  The following code gets the local server name and sets it in the process variable "adobeServerName":

             

            import javax.naming.InitialContext;

            import com.adobe.idp.Document;

            import java.util.*;

            import java.lang.*;

            import java.net.*;

             

            try {

                String computerName=InetAddress.getLocalHost().getHostName();

                 patExecContext.setProcessDataStringValue("/process_data/@adobeServerName", computerName);

            }

            catch (Exception e ){

                patExecContext.setProcessDataStringValue("/process_data/@adobeServerName", "Unable to get Server Name");

            }

             

             

            To get the IP address use:     InetAddress.getLocalHost().getHostAddress();

            To get the fully qualified domain name use:    InetAddress.getLocalHost().getCanonicalHostName();

             

            HTH,

            Kevin

            • 3. Re: Cross Environment Deployment
              vozeldr Level 1

              Thank you very much for taking the time to reply.

               

              I'm not sure that your solution would work since the submission of the form is the start point of the process and I definitely need to know the server as soon as the form is opened. I don't think I'd be able to put a script action and set value (to set the form field) before the start point, would I?

              • 4. Re: Cross Environment Deployment
                Kevin Cavallo Level 4

                Depends on your workflow.  If it's an existing form that's local to the user then you are correct.  If the user requests a form from the server and the first step is to render the form and present it to the user, then you should be able to do it as part of that step.

                 

                Maybe you can give us a little more detail about your workflow and environment?  How are your forms distributed to the users?

                • 5. Re: Cross Environment Deployment
                  vozeldr Level 1

                  Are you suggesting to somehow create a new action profile that would do something in the prepare data process? It doesn't appear to me that by dropping an Execute Script action on the process there is a way that I can create a route from there to the Workspace Start Point (the forms are hosted in LiveCycle Workspace). If I go in to create a new action profile and then create a new prepare data process, there are 2 process variables defined (xmlPrepareData, taskContext) but they do not appear within the process variables and there is no where for me to add any script logic in there.

                   

                  And by the way... my experience with LiveCycle ES 2.5 consists entirely with deploying it in April and migrating the existing forms and processes, so I'm sorry if I don't understand what you tell or ask me or if I can't adequately convey answers back

                  • 6. Re: Cross Environment Deployment
                    Kevin Cavallo Level 4

                    That's OK.  I'm not very familiar with Workspace.  Sounds like the form is displayed first, and then your first Workbench process is hit after the form is completed.  I don't know if there's a way to have a process execute first which would pre-process the form prior to being displayed to the user.  I'll do a little more research on this.

                    • 7. Re: Cross Environment Deployment
                      vozeldr Level 1

                      I was thinking more along the lines of being able to access some property in the XFA API that would tell me what server was hosting the form... something along the lines of xfa.server.name and xfa.server.address would have been nice. I'm hoping there's a way that just isn't that straight forward.

                      • 8. Re: Cross Environment Deployment
                        Kevin Cavallo Level 4

                        I'm having no luck in figuring out an easy way to do this.  The containing application (Reader or whatever) knows the server that generated the form because the submit button action will send it back there.  However I can't find an API method or property that exposes it.  You can try querying the click event target property on the submit button, but I don't think the full URI is available.