Your SlideShare is downloading. ×
Super applied in a sitecore migration project
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Super applied in a sitecore migration project

1,580

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,580
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. SUPER applied in a Sitecore migration project Rogojan Dragoș Constantin Abstract. This document describes the business process model used in a Sitecore migration project, short introduction in Sitecore concepts, an ontology used for Sitecore concepts, advantages and disadvantages on this approach. Keywords: Sitecore, Business Process Model, ontology. 1 Introduction Sitecore is a web content management system built on the Microsoft .NET 3.5 platform. The Sitecore migration project refers to the update of an existing web application which uses an obsolete CMS solution. The new CMS solution is Sitecore and all the existing data must be migrated on the new environment. 2 Sitecore fundamental concepts 2.1 Items In Sitecore, the structure of the application is described as a hierarchy of items that compose the content tree. In general every item is associated with a template. The fields defined on the template, define the fields which appear on the item. 2.2 Templates In Sitecore a template is simply a data structure. In object-oriented programming terms a Sitecore Template is most like a class defining a number of Fields (Properties). In relational database terms Templates function most like tables. Templates can inherit other templates, allowing them to have all the fields of the ancestors. 2.3 Fields Fields are basically equivalent to properties on object-oriented programming, or columns in a relational database. Each Field has a data type which controls what type of user interface component is used to enter data into the field and in what format that data will be stored.
  • 2. 2.4 Presentation components 2.4.1 Layouts (ASP.NET .aspx Web Forms) Layouts define the outermost reusable markup superstructures common to the greatest number of pages. 2.4.2 Sublayouts (ASP.NET .ascx Web User Controls) Sublayouts define markup structures use within a layout or nested within another sublayout. 2.4.3 Renderings Renderings are individual presentation components registered with Sitecore that function as building blocks for published Web sites. The most common Rendering is the XSLT Rendering, used to trasform xml data stored in Sitecore database to HTML. 2.4.4 Placeholders Sitecore placeholders are ASP.NET controls that define named regions of layouts and sublayouts to which other controls bind dynamically at runtime according to layout details. 3 Sitecore concepts ontology Because Sitecore has a powerfull API, a Semantic Web Service based on an ontology which models Sitecore concepts can be created. This ontology can be used to answer a series of competency questions regarding a bussiness process of creating a new page within the website like: ─ Wich characteristics should I consider when designing the items needed for the new page? ─ Which are the templates I can use as ancestor templates for this item? ─ Wich is the best type of field type I should use on the template regarding that I can have as Data Source a set of items? ─ Wich restrictions should I set on the Data Source of this particular field? From all the items in the Data Source set, which ones I can select, which ones I need to hide or only display without the possibility of selection? ─ What presentation element should I use to render this part of html?
  • 3. SUPER applied in a Sitecore migration project 3 3.1 Building the ontology 3.1.1 Enumerate the terms In a general point of view the following terms are considered: Field, Field Type, Field Data Source, Template, Template Section, Item, Item Order, Layout, Sublayout, Rendering, Content Tree, Presentation Components, Content Editor. 3.1.2 Define the classes Taken into consideration the terms above, the fallowing classes can be defined: Field, Field Type, Template, Template Section, Item, Layout, Sublayout, Redering. 3.1.3 Define properties of classes (slots) In Sitecore every item has a Name, an ID (which is a GUID), and a path as simple properties. Next will be defined the complex properties with the following template: propertyName(domain, range). ─ isOfType(Field, FieldType) ─ isFrom(Field, Template Section) ─ hasSection(Template, Template Section) ─ hasFields(Template Section, Field) ─ hasTemplate(Item, Template) ─ hasLayout(Item, Layout) ─ hasSublayout(Item, Sublayout) ─ hasRendering(Item, Rendering) 3.1.4 Creating Instances The last level of the Business Process Model used to create the items needed for a new page in the web application resumes itself to creating instances of the classes defined in the ontology. This process begins with an instance of a Template on which are added Sections, each with Fields that have a Field Type. Next this Template is used to create an instance of an Item. The same steps are repeated if other items are needed (for example items used as data source, or for specific settings – because everything in a CMS must be manageble and the content editor user must be able to do this operation). After all the items needed are defined, presentation components must be added as well. All the items that will be accessed in the web site as *.aspx pages will need to have presentation settings associated. First an instance of a Layout must be added. One or more Place Holders must be instantied as well to define the zones in the layout of the page where other content is supposed to render. Second, Sublayouts or Rendering must be added to complete the layout, also specifying the Place Holders where each one must be put.
  • 4. 4 Sitecore migration Business Process Model 4.1 BPM Overview Sitecore migration in this use case means that a client has an web application that is built using an obsolete system for content management and he wants to be able to use a newer and better application for the same job, provided that the look and feel must not change and all the existing content must be migrated in the new CMS solution. The existing application is managed by webmasters, some of which only act as content editors and some which can provide information about how sections of the web application are designed and implemented. All thing that can migrated ’as is’ must not be changes in the Sitecore solution and this means: cookies used on the old website, javascript code needed for pages allowed to be visited only by authenticated users, external applications used to import data, or translate data (because the website has versions in Arabian and Koreean). The website is broken down into sections and subsections. Every section is described by a Business Analyst, resulting a functional specifications document. Based on each functional specification document, estimations are made for the time a section takes to be implemented. When the client approves the plan, developers get to work using Aglie methology and maximum 1 month iterations. 4.2 SUPER integration The business process presented above is really complex from an IT point of view. Managers and business experts need to be released from this complexity so that the organization can dramatically reduce cost and time required to control the activities of developing this project. The market is very flexible and dynamic and staying on its trend is not easy when a business process model it’s hard to be implemented and this task goes only to IT specialists. The solution for a system that must react quickly to changes is to raise the business process management to the business level where it belongs, from the IT level where it mostly resides now. This can be done by developing ontologies describing business processes, a combination of Semantic Web Services that can be easily composed and orchestrated and using Business Process Management techniques. Starting with the Sitecore ontology (which can be refined and enhaced when needed to get to a generic system that uses semantics to describe the Content Management System behind the business process), one or more IT services must be created. They need to be easily accessible and hide IT elements of implementation by using semantics. This way agility and flexibility is added when the system needs to react quickly to change. Of course management tools for the Business Developement
  • 5. SUPER applied in a Sitecore migration project 5 Manager which are easy to use according to the requirements must be provided also. Another important part is the ability to reuse existing building blocks added up with easy integration. Time is a critical resource in every business so this solution must provide a fast time to market. To wrap it up, SUPER integration will offer a set of tools which provides support on the full life cycle of the Business Process Management and for domain specific logic, for example for the Content Management sector. This way the knowledge about the business process will reside in the process and not in the people that impelement it. The Sitecore migration project is a good example of such a thing. The most part of the knowledge resides in the developers. The next line of people regarding knowledge are the testers and even if they see the system as a black box, they get implementation info from the developers. 5 Advantages and Disadvantages 5.1 Adavatages SUPER integration addresses to critical issues like time and costs. Business Process Modeling returns to business specialists. The system is very flexibile and adapts quikly to change. By building ontologies and Semantic Web Services based on them complex domains can get easily described and extented. Already built ontologies can be reused and extended. 5.2 Disadvantages The is no exact path to build a complete and corect ontology. IT level must be hidden under semantic web services and this implies complex logic according to the domain addressed. 6 References http://www.ip-super.org http://sdn.sitecore.net/

×