12 Replies Latest reply on Jun 26, 2018 9:57 AM by Mayank Gandhi

    Javascript Alerts for Server Side Execution

    Karl Berlin Level 1

      I am on AEM 6.1

       

      I have a form that has Javascript that runs at the client, at the server, and at Client and server.

       

      For the javascript that runs client side, I can use console.log or xfa.host.messageBox to display a message either in the console or browser to aid me along in debugging issues.

       

      However, I cannot seem to find a way to print either a message to server logs, or somewhere else to help with debugging.  If I use console.log or xfa.host.messageBox on the JS that is running on the server, it seems to cause the script not to run, or fail.

       

      I have client run JS that initiates another set of JS on the server, which in turn initiates more JS on the server in another part of the form.  Somewhere in the server side processes, I have an issue.

       

      I have a WSDL call that is run, but it currently only allows me to run it based off one filepath.  If I change the WSDL path to another version of the process (a valid working version), it fails.  I cannot troubleshoot if it is failing to either call the WSDL, or if it's failing after calling it and returning a wrong result.  I need some way to be able to see when something is executing server side, for it to let me know where in the execution it is, to let me know what values the variables are holding, so I can figure out what's different when I change the WSDL path.

       

      How can I print messages to some location for JS executed on the server side of the transaction?

        • 1. Re: Javascript Alerts for Server Side Execution
          smacdonald2008 Adobe Employee

          I am not following you - if you want Server side execution, are you not using Java?

          • 2. Re: Javascript Alerts for Server Side Execution
            Karl Berlin Level 1

            On the form, there's the option to choose a language and where the script is run at.  In this specific case, we are running the javascript at Server (as opposed to client or client and server options).

             

            This javascript is passing values to another javascript function, which then goes and resolves a data connection (calls a WSDL which we have setup with our input and output variables).

             

            We have three environments, alpha, beta, production.  The WSDL call will only run and return a result if the WSDL location is set to the beta environment.  If set to alpha or prod, it fails somewhere resolving the data connection.  I am trying to troubleshoot why it fails, so I need some way to debug that section of javascript.  All of this executes on the Server though, and not on the client side, so I can't use browser alerts.

             

            Here's the following order everything goes at.

             

            We have a validate event that runs, within that validate event we have this:

             

            FDEP.Page1.GlobalCommonData.DesigneeSearch.search.execEvent("click");

             

            That FDEP.Page1.GlobalCommonData.DesigneeSearch.search is a button, and on that button is Javascript that runs at the server, which is the following:

             

            try{

            Global_JS.setFieldProperties(FDEP.Page1.GlobalCommonData.DesigneeSearch, "rawValue", "");

            //Create this input INPUT_EMAIL field in hidden UserPFData subform.

            //Get ServerURI from the GlobalCommonData

            var serverURIValue = FDEP.Page1.GlobalCommonData.ServerURI.rawValue;

            //FDEP.EmployeeSearch.EmployeeSearchType.TextField1.rawValue = serverURIValue;

            requestedDivision.rawValue = FDEP.Page1.sfAccessApproval.District.Divison_Dist.rawValue;

            var successFlag = xfa.resolveNode("xfa.form.FDEP.variables.Global_JS").webServiceConnectClone("GetDesigneeL iveCycleID", serverURIValue);

            //FDEP.EmployeeSearch.EmployeeSearchType.TextField1.rawValue += "\n" + successFlag ;

            if(!successFlag)

            {

            Global_JS.setFieldProperties(FDEP.Page1.GlobalCommonData.DesigneeSearch, "rawValue", "");

            }

            else

            {

            FDEP.Page1.GlobalCommonData.DepDirLiveCycleID.rawValue = DeputyDesigneeLiveCycleID.rawValue;

            }

            //web service returns true or false

            }catch(e){}

             

            You'll see for the successFlag variable, it is resolving a node in Global_JS called webServiceConnectClone.  This is the following code for that function.  It also is set to run at the server.

             

            /*

            Web Service Connect Clone takes the dataconnection name as input and clones the connection with the server URI.

            All validations need to be performed on the field.

             

             

            connectionName : Name of the wsdl Data connection in the form

            //Clones a URL and invokes the web service.

            serverURIParam :   URI of the specific environment

             

             

            return : returns a boolean - true represents dataconnection executed successfully.

            */

             

             

             

             

            function webServiceConnectClone(connectionName, serverURIParam)

            {

             

            try

            {

            var wsdl_Result = false;

                    var dataConnection = xfa.resolveNode("xfa.connectionSet." + connectionName);//Resolve Data Connection

            var ipaddressandport = serverURIParam; // Get server URI

            var clonedDataConnection = dataConnection.clone(1); //Cloning Data Connection

            var oldURL = clonedDataConnection.soapAddress.value; // Dev Server soapAddress

            //app.alert(oldURL);

            //FDEP.Page1.GlobalCommonData.ServerURI.rawValue = "URL is -- " +oldURL ;

            clonedDataConnection.soapAddress.value = oldURL.replace(devServerURI, ipaddressandport);//replace Dev Server Address with current Server URI

            //FDEP.Page1.GlobalCommonData.ServerURI.rawValue += "\nURL is -- " +clonedDataConnection.soapAddress.value;

            if(clonedDataConnection == null)

              {

            return wsdl_Result;

                  }

                

            wsdl_Result = clonedDataConnection.execute(false);

            //app.alert("I am here " + wsdl_Result);

             

             

                  return wsdl_Result;

                

            }catch(err){return false;}

            }                         

             

             

            My apologies if that format is a bit hard to read, I'm not sure if this will help clear up what is happening.  The webServiceConnect clone runs fine for other WSDL calls and dynamically changes their URLs so the WSDL runs in the proper environment.  But it will not dynamically change for the WSDL GetDesigneeLiveCycleID unless we have that WSDL path set to our beta environment.  I need to find out why it won't run for the other environments.

            • 3. Re: Javascript Alerts for Server Side Execution
              DarrenBiz Level 3

              Hi Karl - You mention that you are running AEM [Forms] 6.1 but you don't mention if you are processing the PDF form in OSGi or JEE servers. Again, I assume since you mentioned xfa.host.messageBox you are talking about a PDF form and not an adaptive form.

               

              I believe that server-side XFA JS should output messages to the Livecycle server.log files (if you are processing the PDF on a JEE server). I have never checked what happens when processing a PDF on the OSGi side, so I cant comment there.

               

              There is a good article [1] on how to directly target client-side vs server-side JS if that helps you debug the issue

               

              [1] Client/Server Scripting Differences

              • 4. Re: Javascript Alerts for Server Side Execution
                Karl Berlin Level 1

                If you're referring to this: "On the server use xfa.log.message(); and your debug trace will appear in the server log file."

                 

                I have attempted to add that before, but could not see any message printed to the server log itself.

                 

                I have been told this is an HTML5 form as opposed to a PDF form.  I do not know what that quite means in the realm of PDF vs Adaptive.  How can I determine i I am using OSGi or JEE?

                • 5. Re: Javascript Alerts for Server Side Execution
                  DarrenBiz Level 3

                  Ok that sounds like you need to enable logging for HTML5 forms [1]. These actually render in the OSGi side of AEM Forms and not the JEE (Livecycle) side. This logging will be exposed in the OSGi logs folder and not the JEE application server logs folder. This will be located in (depending on what you have installed) <forms-install-folder>/[crx-respository|crx-quickstart]/logs/error.log

                   

                  You should also be able to log out directly to the Javascipt console as you have been doing.

                   

                  Bear in mind that since HTML5 forms only uses a subset of the Javascript available for PDF [2] some script will not work in HTML5 render method. You can actually target HTML rendering in your scripts by examining xfa.host.appType. If appType == "HTML 5" then you are rendering in HTML, if its "Reader" you are rendering the XDP as a PDF, etc.[3]

                   

                  [1] AEM 6.0 Forms Help | Enable logging for HTML5 forms

                  [2] AEM 6.0 Forms Help | Scripting support for HTML5 forms

                  [3] https://books.google.com.au/books?id=rRQQAgAAQBAJ&pg=PA205&lpg=PA205&dq=xfa.host.appType&s ource=bl&ots=IDG8jO4QyS&sig=OL…

                  • 6. Re: Javascript Alerts for Server Side Execution
                    Karl Berlin Level 1

                    I have to get with the other team that manages the configuration manager, but I did try to enable logging for client side through building the request parameter with desired logging levels.  The issue I have, is the above JS executes when the form runs through validations.  Those validations start when a user hits the submit button.  Generating the request parameter URL, I do not have any sort of submit or save etc type button, the form just ends and is blank where those buttons usually are.

                     

                    I appreciate the information, this looks like a step in the right direction possibly.

                    • 7. Re: Javascript Alerts for Server Side Execution
                      Mayank Gandhi Level 4

                      Hi Karl,

                       

                      Referencing below two points:

                       

                      "The WSDL call will only run and return a result if the WSDL location is set to the beta environment.  If set to alpha or prod, it fails somewhere resolving the data connection. " & " If I change the WSDL path to another version of the process (a valid working version), it fails"

                       

                      ->Have you tried Soap UI or any other client to check whether you are able to make a connection to WSDL of all the three environment from the same machine where you are currently debugging the form?

                       

                       

                      • 8. Re: Javascript Alerts for Server Side Execution
                        Karl Berlin Level 1

                        Have not tried SoapUI from my machine.  May have restrictions on installing it.  I can install it on my personal machine and attempt to make the connection.

                         

                        If I input the path into my browser, it does load an XML file, and all three environments show the same XML (barring the area that displays what the URL is for the process itself).

                        • 9. Re: Javascript Alerts for Server Side Execution
                          Karl Berlin Level 1

                          Calling the WSDL paths results in the following:

                           

                          For the Prod WSDL path, I receive the expected response

                           

                          For Alpha, I receive the following:

                           

                          <?xml version="1.0" encoding="utf-8"?>

                          <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

                             <soapenv:Body>

                               <soapenv:Fault>

                                 <faultcode>soapenv:Server.Unauthorized</faultcode>

                                 <faultstring>

                                 </faultstring>

                                 <detail>

                                   <ns1:hostname xmlns:ns1="http://xml.apache.org/axis/">Alpha-Server-Address</ns1:hostname>

                                 </detail>

                               </soapenv:Fault>

                             </soapenv:Body>

                          </soapenv:Envelope>

                          • 10. Re: Javascript Alerts for Server Side Execution
                            Mayank Gandhi Level 4

                            Hey Karl,

                             

                            Does your WS require authentication and what was the result from SOAP ui?

                            • 11. Re: Javascript Alerts for Server Side Execution
                              Karl Berlin Level 1

                              The above response was from an API test, I imagine similar to what SOAPUI does, but was done through UFT.

                               

                              Navigated to adminui and looked at the security tab for the process that the WSDL was for.  Require authentication was set to Yes, but did not have any username or password set.  It was changed to run as System, and I am able to successfully have the Alpha URL load. I will need to change it back to that URL, and see if it successfully clones again based off environmental shifts.

                               

                              This post helped lead me to that Security tab

                               

                              SOAP Endpoint - Unauthorized Errror

                              • 12. Re: Javascript Alerts for Server Side Execution
                                Mayank Gandhi Level 4

                                Hi Karl,

                                 

                                Good to know that it works now, please let us know if you need any help further.