xpages: what can stop code stop while saving a page?

UPDATE AT THE END: SOURCE OF PROBLEM IDENTIFIED

I have a page, based on a form that has been stripped of most computed fields from the previous version of the app (so docs can actually pass the computewithform function), and I have an issue while saving documents. I have documents that were created in the Notes client (previous app versions), that have been converted to mime, and some documents that were created in the new xpages app, with CKEditor, saved in a rich text field that is flagged to store as MIME as well.

I have a button to "publish" the document. The code works fine for documents created in the new app, but it seems to stop somewhere for documents that were created in the previous app version.

Here's what IE traps as far as http traffic goes:

A case that works:
/mydb.nsf/page.xsp?action=editDocument&documentId=353B2 HTTP    POST    302     244 B   218 ms  cliquer 0   31  0   187 0   1761
/mydb.nsf/xPublish?OpenAgent&docid=487A3447CFA36BF085257EE400626485 HTTP    GET 302     190 B   141 ms  cliquer 218 16  125 0   0   1620
http://myserver.com/mydb.nsf/dx/test_13col00    HTTP    GET 200 text/html   55.71 Ko    312 ms  cliquer 359 0   0   32  0   1308

A case that doesn't work:
http://myserver.com/mydb.nsf/page.xsp?action=editDocument&documentId=353BA  HTTP    POST    302     244 B   188 ms  cliquer 0   32  0   156 0   156
/mydb.nsf/xPublish?OpenAgent&docid=E0E13322928B8F9685257EE400628B0A HTTP        (Abandoned)     193 B   < 1 ms  cliquer 188 0   0   0   0   156

The code in the "Publish" button is:

//set status
    if(getComponent("publishLater1").getValue() == "1") {
        pageDocument.replaceItemValue("status", "Scheduled Publication");
    } else {
        pageDocument.replaceItemValue("status", "To Be Published");
    }

    //so we know the document has been saved (for drafts, when cancelled)
    pageDocument.replaceItemValue("hasBeenSaved", "1");

    //init some fields (res_title, ...)
    if(!(pageDocument.hasItem("res_title")) || pageDocument.getItemValueString("res_title")==""){
        pageDocument.replaceItemValue("res_title", buildResTitle(pageDocument.getItemValueString("subject")));
    }
        
    //set VERKEY AND VERNUMBER if not already set
    if(pageDocument.getItemValueString("VERKEY")==""){
        pageDocument.replaceItemValue("VERKEY", @Unique());
    }
    if(pageDocument.getItemValueString("VERNUMBER")==""){
        pageDocument.replaceItemValue("VERNUMBER", 1);
    }

    //save pageDocument
    pageDocument.save();

    //send to publish agent
    //remove the lock doc
    //unlockDoc(pageDocument.getDocument().getUniversalID());

    //for scheduled publications, a LotusScript agent will do the work
    var res=facesContext.getExternalContext().getResponse();

    if(getComponent("publishLater1").getValue() == "0") {
        // Now load the publish Agent
        var baseUrl = @Left(facesContext.getExternalContext().getRequestContextPath(),".nsf") + ".nsf/"; 
        facesContext.getExternalContext().redirect(baseUrl + "xPublish?OpenAgent&docid=" + pageDocument.getDocument().getUniversalID());
        //res.sendRedirect(xPublish?OpenAgent&docid=" + pageDocument.getDocument().getUniversalID(), false);
    } else {
        //send to the drafts view, to show it has the clock icon in the draft view
        context.redirectToPage("adminDrafts.xsp");      
    }

I'll spare the détails of the LotusScript agent that is called (xPublish), but the redirect in that code is done that way:

Print "Location:" + db.Filepath + "/dx/" + res_title

According to IE's http log, it seems that something is not going quite right while running the code in the button, and it causes the http post to be abandoned and therefore, the call to the LotusScript agent is also abandoned, not redirecting the user to the newly published page. Instead, the user is redirected to this URL:

http://myserver.com/mydb.nsf/page.xsp?action=editDocument&documentId=353BA

The big problem here is that this page (the draft version) is deleted in the LotusScript agent, so that URL gives an error page.

If you Wonder why the publish code is in LotusScipt, it's because we also have a scheduled agent that runs daily and publishes "scheduled publications" set to be published in the future. It is to avoid have to maintain both SSJS and LotusScript code.

Any clues to why this happens?

UPDATE

Ok, it seems that the code works OK, but it's the redirection in the LotusScript agent that doesn't do the job. This is what I was using to redirect to the page that was just published:

Print "Location: http://ourserver.com/mydb.nsf/dx/" + res_title

It was working at one point, but now it seems to be causing issues. the funny thing is that the agent works fine with documents we create from scratch, but not for documents that have been created in the previous version of the application... Still no clue how to fix that. What is the way to do a redirect from LotusScript for xpages?

Solution

Ok, I got this all worng. It is still a bit weird, as it was running OK for new documents but not OK for the ones created in the previous version of the application, but I was calling the LotusScript agent the wrong way.

By looking at how it was done in the IBM Wiki Template, I noted that they were calling a LotusScript agent in a different way, and I tried that. Turns out it works great: the code is called and the redirection is made without any issue.

Here is the way I now call my agent and do the redirect:

var agent = database.getAgent("xPublish");
var res = facesContext.getExternalContext().getResponse();
agent.runOnServer(pageDocument.getNoteID());    
res.sendRedirect(@Left(facesContext.getExternalContext().getRequestContextPath(),".nsf")+".nsf/dx/"+pageDocument.getItemValueString("res_title"));

As I said, not sure why my original code stopped working, and had problems only with docs created in the previous version of the app, but the new code works on all docs, all the time. If IBM does it this way, I guess it might be the right way.

That wiki app has a lot of code in it! Have a look at it to get some valuable pièces of code or to get inspiration!!!