Automatic Page Copies

1. Automatic Page Copies A publish trigger and web services case study Daniel Horwitz andDarren Schaumann, ProHealth Care

2. Where’s Darren? In Tahiti on a large boat sipping margaritas and loving life OR In labor and delivery waiting for my second child to be born.

3. Detailed Information • Information on downloading the detailed speaker’s notes, Java code, style sheets and build configuration will be made available at the end of this presentation.

4. Introduction • Our policies and procedures system was difficult to use, and even harder to maintain. • Using a publish trigger and web services, we were able to simplify our system. • Only one copy of each policy and procedure is updated.

5. Problem Statement • Policies and procedures defined • Current situation • Challenge

6. Definition • Policies and procedures are the documented processes and guidelines that the corporation and people are required to follow.

7. Definition • Policies can apply to multiple entities within the ProHealth Care system.

8. Definition • Each policy and procedure document should contain either a policy section, a procedure section or both.

9. Current Situation • Users note that searching on the current site is difficult to use.

10. Current Situation • Each entity has a directory structure to browse, but they all have different structures.

11. Current Situation • Policies were written in Microsoft Word™ and then converted to PDF files. • They have many different, and inconsistent, formats.

12. Challenge • Simple search and site hierarchy for finding policies. • Use content management for archiving and workflow. • Single source policy applying to many places in the hierarchy. • Have all the policies use the same format.

13. First Attempt • Display document in multiple places using ‘references’. • Unable to get navigation to be based on user’s current location in site. Need separate index block generation for each folder where the policy appears.

14. ProHealth Solution • Build policies out of a series of HTML blocks. • Allow content editors to edit only the source policies. • Include entity and category information as metadata. • When source policy is published, create or update copies of the policy at all the appropriate places in the site hierarchy, then publish the copies.

15. User View • Organization • Home page • Search • Left Navigation • Right Navigation • Policy Display

16. User View - Organization • Policies are organized by entity and category.

17. User View – Home Page • Policies and procedures home page has left-hand navigation and search. • Both dynamically display all entities.

18. User View - Search • Using Google™ search appliance. • Finds policies under each applicable entity and category.

19. User View – Left Navigation • Left-hand navigation block allows users to browse for policies in the site hierarchy.

20. User View – Right Navigation • Right navigation displays policies immediately under entity or policies within current category.

21. User View – Policy Display • Displayed as series of HTML blocks.

22. Content Editors • Content editors see only the source copy of the policy document. • The different pieces of the document are all edited as blocks.

23. Content Editors • Defining entities and categories to which the policy applies.

24. Content Editors • Editor must enter policy, definitions and procedure into separate blocks.

25. Content Editors • When the content editor publishes the source, all the copies are published. • Content editors can publish the folders containing the copies. • When creating a new policy, the creator selects a different page type for a policy only, a procedure only or a combined policy and procedure.

26. Site Administrators • Only site administrators can see the copies. • Site administrators set up entity and category selection blocks. • Site administrators create folders and index pages for all the entity/category combinations.

27. Style Sheets • The style sheets take advantage of copies of all the policies being in the correct place. • For navigation, the “current” attribute is the key to locating the system folder which is the user’s current location in the site.

28. Style Sheets – Left Nav • Left-hand navigation displays the user’s current location in the site. • Style sheet called Left PandP Parent Children, because it displays both the parent (entity) information and the children (category) information.

29. Style Sheets – Left Nav • If current is an entity, displays all the entities, highlights the current and displays the categories of the current entity. • If current is a category, displays all the entities, highlights the current and displays just the current category. • If no current, then displays all the entities, with no current entity highlighted.

30. Style Sheets - Search • Search, on the right hand side on the home page, displays the search block. • Style sheet is PandP Search. • Handling of two columns loosely based on Home Left Navigation.

31. Style Sheets – Right Nav • When user’s current location is an entity, display that entity’s policies that do not have a category. • Style sheet called PandP Children because it displays an entity’s children.

32. Style Sheets – Right Nav • When user’s current location is a category, display the category’s policies. • Style sheet called PandP Grandchildren because it displays an entity’s grandchildren.

33. Style Sheets - Navigation • The navigation style sheets use an index block as their source. Generating the XML for an index block takes some time. This seems to be the main bottleneck for publishing. • Navigation must be rendered based on user’s current location so that all the links are correct.

34. Style Sheets - Policies • The policy_procedure style sheet displays the selected policy. • The policy is simply a list of blocks, which are displayed in order. • The entities block is built from the “Site” dynamic-metadata element, which is a sibling of the system-data-structure element.

35. Publish Trigger • Notes • Vocabulary • High-level Algorithm • Web service calls used • Publish trigger interface • Web services interface • WebservicesUtils • Building an Asset for a psuedo-policy • Build Notes

36. Publish Trigger - Notes • In order to publish an asset, that asset must exist. • When an asset is published by the user, or via the web service, it is placed on a queue. • A single thread in the Cascade server takes an item from the queue and publishes it.

37. Publish Trigger - Vocabulary • Actual policy: The source policy, which is edited by the content editors. • Pseudo-policy: A copy of the source policy, which is used to publish copies of the actual policy.

38. High-level Algorithm - Notes • Low-level details are in the Java code to be supplied later. • Publish trigger is called for every destination of every document being published. • Upon return from the trigger, the triggering document is published by Cascade to the specified destination.

39. High-level Algorithm • I) Examine the entity type and entity path from the publish information. If not a policy, do nothing. • II) Read the policy being published. • III) Look at the metadata. If a pseudo-policy, do nothing.

40. High-level Algorithm - IV • IV) Using the applicable entity and category lists from the metadata, loop through each pseudo-policy associated with the actual policy. • A) Try to read the pseudo-policy.

41. High-level Algorithm - IV • B) If the pseudo-policy doesn’t exist: • 1) Create the pseudo-policy. • 2) Remove non-administrator access to the page. • 3) Publish the indices to its parent and grandparent folders.

42. High-level Algorithm - IV • C) If the pseudo-policy exists but the actual policy has been updated later: • 1) Update the pseudo-policy to reflect the actual policy’s content. • 2) Remove non-administrator access to the page.

43. High-level Algorithm - IV • D) Publish the pseudo-policy.

44. Web Service Calls Used • Only assets being manipulated are pages. • read() • create() • edit() • editAccessRights() • publish()

45. Publish Trigger Interface • See “Publish Triggers” in the knowledge base for details.

46. Publish Trigger Interface • SDK contained in CascadePublishTrigger.zip • Use publishtrigger-5.5.jar • Interface is part of Cascade installation. Don’t include interface classes in the publish trigger archives.

47. Web Services Interface • See “Web Services Skeleton Project” in the knowledge base for details.

48. Web Services Interface • Download axis 1.4 from http://ws.apache.org/axis. • Make the jar files inaxis-1_4/webapps/axis/WEB-INF/lib available. • Get a current copy of the wsdl file using a browser. Cascade server must be running. URL is<server-base>/ws/services/AssetOperationService?wsdl. • Build interface classes using org.apache.axis.tools.ant.wsdl.Wsdl2javaAntTask. • Careful, AssetOperationService_address is based on how the wsdl file was addressed by the browser. Production interface must be built from production wsdl file.

49. WebservicesUtils • Get com.cms.webservices.WebservicesUtils from Cascade+Webservices.zip. • Pages contain a number of elements where an identifier or path must be supplied, but not both.

50. WebservicesUtils • To set up a page for create() or edit(), read the page, call nullPageValues(), then perform application-specific editing. • If you don’t use nullPageValues(), beware of dragons.