Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
9 replies Latest Post - ‏2010-05-18T22:18:21Z by smalabarba
JohnRyan
JohnRyan
6 Posts
ACCEPTED ANSWER

Pinned topic Issue with ECM publish wizard dialog.

‏2010-05-05T15:29:17Z |
I am having some issues using the ECM publish wizard dialog in Quickr. Getting some functionality, then errors. The following link is to a file that have more details and screen caps. Any help is greatly appreciated. I would attach the file...but the forums seems to have trouble with that..so, here's a link.

http://www.dlitools.com/dlitools/dlitoolshome.nsf/0/E6EFC1F0EF093BD58525771A0054484A?opendocument
Updated on 2010-05-18T22:18:21Z at 2010-05-18T22:18:21Z by smalabarba
  • smalabarba
    smalabarba
    12 Posts
    ACCEPTED ANSWER

    Re: Issue with ECM publish wizard dialog.

    ‏2010-05-05T18:41:56Z  in response to JohnRyan
    Which ECM back end (FileNet P8 or DB2 Content Manager) are you using, and what version levels of ECM Quickr Services and Quickr?
    One possible cause of this error is that you're using a FileNet back end and have mismatched versions of IBM FileNet Services for Lotus Quickr and the Lotus Quickr server. It won't happen with GA versions, but might if you're using an early beta/tech preview of IBM FileNet Services for Lotus Quickr v1.1.
    • JohnRyan
      JohnRyan
      6 Posts
      ACCEPTED ANSWER

      Re: Issue with ECM publish wizard dialog.

      ‏2010-05-05T20:39:21Z  in response to smalabarba
      Our back end is Domino. Using Quickr 8.5 CD4. There is little to no documentation...so we are blindly trying to guess at some of this stuff.
      I think what is happening is that the Next button click on the dialog is trying to make a call to our system and looking for it to return authorization...that a user can actually publish to the folder they've selected. Problem is, we don't know what the xml (atom feed) needs to look like. I'm not sure that's what it is...but it seems like that. Additionally, we don't know what node in the folder feed xml it's looking to to get the url to post a get request to.

      So, do you have this working with something like Filenet/Content Manager? I would be grateful to know what the code is trying to do and the formats of the responses and so on. As you can see in the screens I put in the file of the link of my other post that we have been able to discover the xml format of the atom feeds for showing the folders of our system...a bit of hacking together samples and so on.
    • JohnRyan
      JohnRyan
      6 Posts
      ACCEPTED ANSWER

      Re: Issue with ECM publish wizard dialog. A Question...

      ‏2010-05-05T22:06:01Z  in response to smalabarba
      Scott, wondering...do you have a Quickr - ECM Publish scenerio that you have access to where you are publishing to FileNet/CM??

      Our problem is lack of documentation. We have very little. It would be helpful if we could sit with someone who has an implemention just so we could see what the xml is. I mean where we are now...we are just clicking on the Next> button on the publish dialog...and assuming about what it's trying to do. So, we assume when clicking it is asking for a feed to determine if the user has access to the folder in our ECM...fine...but we have no idea about what the XML is supposed to look like to return a response...and we can't find it in any documentation..although we are still looking...what else right?
      Could you help me out? I mean...if you have an implementation could we run fiddler or something and capture the xml response when you click on a button...I think it is pretty much just that simple...
  • JohnRyan
    JohnRyan
    6 Posts
    ACCEPTED ANSWER

    Re: Issue with ECM publish wizard dialog. SOME MORE INFO

    ‏2010-05-05T21:58:39Z  in response to JohnRyan
    As we dig away, we noticed that perhaps the Next button (in the Publish dialog) we're clicking on is querying our ECM for an atom feed/xml that is telling it that the user has the rights to publish a document from Quickr to the ECM folder. With this assumption in hand, we tried to find out where the next button was getting it's information to submit to our Domino Docova server.
    We found that it seems that when we clicked on the Next> button on the dialog, it is trying to launch the href value of the <link> node in an <entry> which has rel=self as a parameter.

    So, now I think I only have one specific question...and hope that it will be easy to pass on to the dev group for some answers.

    After clicking on the Next> button on the Publish to External Location dialog, it will call a URL (we think we can handle that)...but what xml (atom feed) format is it expecting back?? We think with the proper xml response...the Quickr code will be able to move use forward to the next dialog at least.
  • smalabarba
    smalabarba
    12 Posts
    ACCEPTED ANSWER

    Re: Issue with ECM publish wizard dialog.

    ‏2010-05-06T23:35:30Z  in response to JohnRyan
    We don't have any publicly accessible systems right now. But, Lotus does have plenty of documentation on the Quickr REST API. This developerWorks series would be a good place to get started: http://www.ibm.com/developerworks/lotus/library/quickr-rest/. See also the Lotus-related links on this forum's "Useful Links" sticky post, or the Quickr wiki at http://www-10.lotus.com/ldd/lqwiki.nsf.

    In your particular case, the publish wizard is making a library feed request with the parameter acls=true, and looking for something like this in the response to determine the user's permissions.
    
    <td:permissions>GrantAccess,ViewContent,Delegate,View,LockOverride,ViewProperties,Edit,AddChild,Delete,EditProperties,AddFolder,EditContent</td:permissions>
    

    It doesn't see the minimum level of permissions required to publish documents.

    If publishing to a FileNet or Content Manager system, try refreshing the software versions as I suggested earlier. If you're publishing to Quickr Domino, try one of the Lotus forums (there's a list on the Quickr wiki) -- this forum is specific to the ECM repositories.

    Hope this helps.
    • JohnRyan
      JohnRyan
      6 Posts
      ACCEPTED ANSWER

      Re: Issue with ECM publish wizard dialog.

      ‏2010-05-07T15:07:44Z  in response to smalabarba
      Thanks for the info. Yes indeed, we are familiar with those links and that documentation...however, there is no information about the ECM publish atom feed formats and such...hence me asking about if you have something we can see from a post/request standpoint...in lieu of documentation...that's the only discovery method we have. That's ok...we can put in a request to set up the environment. Initially we are publishing to our ECM solution, a Domino solution...REST is quite Quickr centric in that it is about how we can create/edit/delete/view content from our ECM...which we'll tackle next.
      Anyway, thanks for your replies...I appreciate it.
      • smalabarba
        smalabarba
        12 Posts
        ACCEPTED ANSWER

        Re: Issue with ECM publish wizard dialog.

        ‏2010-05-10T19:56:04Z  in response to JohnRyan
        OK, I see what your question was about. This should help.

        The ECM public operations use only the standard Quickr APIs (REST, and a little of the web services). Two products, IBM FileNet Services for Lotus Quickr and IBM DB2 Content Manager Services for Lotus Quickr, implement the Quickr APIs for their respective back ends. Each one is an enterprise application that "sits" between the Quickr client application and the ECM backend server, translating Quickr API calls into operations on the underlying repository.

        So, the Atom feeds used in ECM publish are standard Quickr REST feeds. The XML looks the same, no matter which implementation of the Quickr services API you are publishing to. There are only cosmetic differences. For instance, FileNet document and folder IDs look a little different than Quickr Domino IDs, and the backends don't all sort results in the same way.
        • JohnRyan
          JohnRyan
          6 Posts
          ACCEPTED ANSWER

          Re: Issue with ECM publish wizard dialog.

          ‏2010-05-18T16:14:21Z  in response to smalabarba
          Yes, so, FileNet and CM call Quickr APIs (REST). That's fine, there is a lot of documentation around the endpoint to call and the methods/properties (I'll say) available. That's great, however, we are at the final dialog of the ECM publish wizard (we believe), and when we click the Done button, it posts a SOAP message to the "/dm/services/DocumentService..." URL. I think we need to be able to change that. Do you have any idea where to do that? I mean, if we used the ContentService wsdl in order to create our own J2EE stubs...we'd need to change that...however, we can't seem to find where that should be changed. We have found it hardcoded in a .js, but, if we change it, other funky things happen...like a blank properties/meta dialog shows up. Any inspiration on that would be helpful.
          • smalabarba
            smalabarba
            12 Posts
            ACCEPTED ANSWER

            Re: Issue with ECM publish wizard dialog.

            ‏2010-05-18T22:18:21Z  in response to JohnRyan
            The first thing the ECM publish wizard does after you hit "Done" is make a web services DocumentService::getDocument() call to the ECM server, to check whether or not the document already exists. That's what you're seeing. From there, it's conditional -- for example, if the doc exists, the wizard will check it out before uploading new content.

            I don't think you can change the API calls that the wizard makes. You can only change the URL that it publishes to, and the URL has to be for a server that implements the Quickr services API.

            If you're developing your own Quickr services implementation, you may want to check in with the Lotus team (try one of the forums mentioned earlier). They could offer some guidance as to what is supported, and what API calls would have to implemented for publish to work.