Portlet Lifecycle and Registry Information

Owned by Dustin Schultz
Last updated: Oct 08, 2008 by Roger V. DespresVersion comment
3 min read

Notes

There is a need to maintain the lifecycle of portlets. From beginning to end there needs to be ownership of content and an understanding of maintenance from anyone wanting to develop content in the portal. Also, who should be contacted if the portlet fails? An agreement with the help desk or support team? All content should have a functional and technical stakeholder.

Discussion about looking to extend portlet manager to possibly incorporate this.

Metadata

  • Functional owner, including contact information
  • Technical owner, including contact information
  • Support plan, e.g. central Help Desk, including contact information
  • General SLA information
  • Planned outages and custom error messages

Actual Data

  • On what layouts?
  • How many users have added it to their layout?

Things to consider

  • Support arbitrary number of CPDs in global CPD registry; add a global CPD; more default metadata?  Support for arbitrary metadata
    • Bring metadata into portal for monitoring and support workflow; notify the right people;
    • Framework needs to capture the data; then what we do with it is up to institution.
  • Policy question - what should the default metadata grow to be?
  • The portal is usually considered to be 24 X 7 but the content it displays is not, i.e. weekly database maintainence
    • Consider that the framework is able to handle this?

Other Additional Data

Peoplesoft Portal has a content registry that may be worth looking into as something to model against. Hopefully looking for screenshots or more information on this since not all universities have this.

A Portlet?

Maybe a portlet to view the data and metadata. It could also quickly produce reports that export this data for external reporting options.

New Portlet Vetting Process

From Yale:

  • For new content, a call to portal team to describe proposed content
  • There are Portlet and Content Developers. The later is expected to NOT develop and deploy JSR-168 Portlets, but instead provide a backend service that generates XML (e.g. REST,  Web Service)
  • All new content looking to be published to Portal is considered a new project (or sub-project). The Portal team will facilitate, however not necessarily manage the project.
  • Looking to establish a standard set of questions - governance
    • SLA expectations
    • Registry information
    • Review of how the portal real estate is used
    • What layout should content be included
    • Is there an existing layout
    • Can this new content be combined with existing content
    • SDR
    • Performance review - how do we certify new content?
    • What happens if they have been showing an error page and is not fixed?  What do you do? Disable? Delete?
    • Centralized portlet developers
    • Distributed content providers
    • Ideally content will be delivered through an ESB

From Wisconsin: (Note from meeting should be reviewed)

  • Service team - leader is a product manager - public face but not highly technical; gathers information; can it use existing infrastructure or needs something new?
  • Info passed to tech team for additional evaluation
  • Topics
    • Who will do the work
    • How paid for
    • Guidelines for content
    • Branding
    • Look and feel
    • Performance
  • QA Environment
    • Content provider responsible for testing and final QA
    • Load testing runs automatically
  • Before go-live
    • Help desk document
      • Who to contact
      • Documentation for knowledgebase - internal and external
        • How should calls be handled

Possible Actionable steps