2 Replies Latest reply on Aug 26, 2009 2:46 PM by J41

    Publishing RoboHelp projects using third-party app and RH command prompt

    J41

      Hi -

       

      I am curious to know if anyone has used the RH command prompt to publish a RH project using a third party application - i.e. homegrown app?

       

      I'm thinking of creating an application that will allow RH users register their projects for knowledge management purposes. It would act somewhat like an LMS where users could post their dev files on a network share. When ready to review with the customer, the would use the registration tool to push the project to preview. The app would call the RH command prompt using a server side technology, in my case .NET, and supply the necessary arguments and push the generated project to preview. Once it had been reviewed and ready, then the user could push to production.

       

      Any thoughts on this - reasons why this wouldn't work, good, bad, ugly, alternatives? - all constructive comments welcome

       

      Thanks

        • 1. Re: Publishing RoboHelp projects using third-party app and RH command prompt
          Captiv8r Adobe Community Professional & MVP

          Hi there

           

          I see some flaws with that.

           

          J41 wrote:

           

          It would act somewhat like an LMS where users could post their dev files on a network share.

           

          Dev files need to always be local. Placing on a network share for the purposes of using RoboHelp to compile or generate is risky business and may explode in your face. LMS to me means Learning Management System. Those are typically used for eLearning. RoboHelp does help systems. Captivate does eLearning. So you are losing me with your LMS reference.

           

          When ready to review with the customer, the would use the registration tool to push the project to preview.

           

          I'm lost. What "registration tool" are you even referring to here? Or is this what you are planning on creating and that's what you are choosing to call it?

           

          The app would call the RH command prompt using a server side technology, in my case .NET, and supply the necessary arguments and push the generated project to preview.

           

          There is no "preview" of projects. Preview of individual topics, sure. But not for a project. There is only compile or generate to create the final output.

           

          Once it had been reviewed and ready, then the user could push to production.

           

          Sounds like what one might typically accomplish using RoboHelp in a typical development cycle. You edit content on the local hard drive. If a review is needed, you compile or generate the content and place the output on a server. After approval is complete the content is then copied to the production server.

           

          Sure sounds like you are attempting to reinvent the wheel in many situations here.

           

          Cheers... Rick

           

           

          Helpful and Handy Links

          RoboHelp Wish Form/Bug Reporting Form

          Begin learning RoboHelp HTML 7 or 8 within the day - $24.95!

          Adobe Certified RoboHelp HTML Training

          SorcerStone Blog

          RoboHelp eBooks

          • 2. Re: Publishing RoboHelp projects using third-party app and RH command prompt
            J41 Level 1

            Thanks for the quick replay Captiv8r!

             

            I apologize for not being more concise. For the sake of argument, lets say I have the following assumptions:

             

            • 100k plus users (content viewers)
            • 7 server environment (1 - dev with daily backups, 2 preview and 3 production loadbalanced servers)
            • Issues with knowledge management - orphaned help topics and RoboHelp projects, etc...
            • Lack of reporting capabilities
            • Lack of evaluation capabilities - comments and ratings
            • No "email to friend" feature
            • RoboHelp developers
              • use local machines, but when finished or need to collaborate store files on the dev server - understand you concern, but with daily backups for finished projects, we don't really have to worry too much.
              • Are not technical - can develop content, but can't write scripts to include in their projects. However, they can function within the IDE and include scripts written by others.

             

             

            What I'm trying to decide is whether or not to build an application that can mitigate the above problems within the above contraints and resources.

             

            My idea is to create an EPSS (Electronic Performance Support System/Solution), not an LMS - sorry poor use of the term. Also the term "registration tool" is just a generic term to indicate the purpose - to capture meta data associated with the RoboHelp project and register it in a database.

             

            The flow would be as follows:

             

            1. Developer does the preliminaries - analysis, documenting structure, help topic names, etc...
            2. Developer registers meta data associated with knowledge management - i.e. developers name, project information, various keystakeholders, description, dates, whether to include other features when published like comments, ratings, etc... 
            3. App registers the data in the database, creates a folder on the development server with the appropriate permissions and emails the developer with the development directory they're to store the content when ready.
            4. Once ready, the developer goes back to the registration tool and indicates the files are on the dev server and ready to be previewed by the customer. - The app will then look up in the database where the files are located on the dev server and match it with the preview server. Then, it will call the RH command prompt, pass the necessary variables, wrap (add needed code - JavaScript and Meta tags for comments and ratings) and publish the files to the preview server, send an email to the appropriate stakeholders with the location of the project for review.
            5. Once the developer and stakeholders reconcile the developer will go back to the tool and indicate it is ready for production and push it on through.

             

             

            Hopefully it is more clear. Do you see any value in it considering the above assumptions?

            Thanks again for you comments.