Customising the WebSphere Service Registry and Repository user interface

This article describes WebSphere Service Registry and Repository and its WSRR Studio, and shows you how to use them to create a customized user interface, complete with custom business models and a custom life cycle.


Introduction to WebSphere Service Registry and Repository

IBM® WebSphere® Service Registry and Repository (WSRR) enables you to store, access, and manage service metadata that is used in the selection, invocation, management, governance, and reuse of services in an SOA. In other words, it is where you store information in your or other organizations' systems about services that you already use, plan to use, or want to be aware of. For example, an application can check WSRR just before invoking a service to locate the service instance that best satisfies its functionality and performance needs. WSRR also plays a role in other stages of the SOA life cycle. It contains information about the interfaces, operations, and parameters of services, plus a metadata repository, thus providing a robust, extensible framework to suit the diverse nature of service usage. In addition, WSRR provides management and governance capabilities that enable you to get the most business value from your SOA. In sum, WSRR is a central and essential component of your SOA.

This article is based on WSRR V6.3 with Fix Pack 1 or later, or WSRR V7. Where activities differ between versions, the differences will be spelled out. To benefit from this article, you should have a basic understanding of WSRR.

Article scenario

This article uses a simple scenario that demonstrates WSRR customization. The scenario involves bakers and cafes, with cafes creating orders that bakers elect to fulfill.  The cafes and bakers are users in a user registry (such as LDAP), and all orders are represented by business models. The orders are then transitioned through a custom life cycle from creation to completion.  A more detailed description of each aspect of the scenario is given below in each section of the article.

Creating business models

Business models enable you to represent objects that are important to your organization inside WSRR.  They define a template for instances of business objects and let you specify properties, relationships, and custom cardinality. Business models are defined using Web Ontology Language (OWL).  For example, to represent physical pieces of hardware in WSRR, you would create an OWL file with properties representing information about the hardware, such as hostname, IP address, operating system, processor type, and so on.  OWL lets you specify the type of these properties, so hostname would be string, whilst operating system might be an enumeration with specific options specified.  You can also specify that there must be a relationship to an instance of another business model, perhaps the owning organization in charge of the hardware.  WSRR can enforce these rules and prevent the creation of an instance not conforming to the model.

From the point of view of the scenario, Figure 1 shows the hierarchy of the business models.  The top-level object is the order -- an abstract class (it’s not actually abstract as this concept doesn't exist in OWL) that is inherited by Food Order and Box Order.  Box Order is used by the bakers to order packaging for their produce, while Food Order is another abstract class inherited by the three food types’ actual order classes -- doughnut, pasty, and iced bun. At each object level, there are the properties and relationships relevant to each object.

Prior to WSRR V6.3, OWL had to be created by hand or using third-party tools, but now WSRR includes WSRR Studio, an Eclipse-based application that helps you create models in UML and generate WSRR configuration artifacts. To use WSRR Studio to create the model shown in Figure 1:

  1. Assuming WSRR Studio has been installed, start WSRR Studio and create a new WSRR Configuration Project:
  2. Once WSRR Studio is loaded, click File => New => WSRR Configuration Project. You must now enter a name, such as CafeAndBakerScenario, and select the template to use.
  3. If you are using WSRR V6.3, select Basic Profile. If you are using WSRR V7, select Basic Profile for the version of WSRR that you want the profile to work for. Click Finish. You now have a configuration profile in which to create your model.
  4. Create the model: Expand CafeAndBakerScenario, right-click Models, and select Create WSRR Business Model. In the resulting wizard, enter:
    WSRR V6.3 fieldWSRR V7 fieldDescriptionInput
    UML Package nameUML package nameFile name of the model and must be unique in the project.OrderModel
    Ontology base URIBase URIURI to uniquely identify this model. It should start http://
    Ontology labelLabelUsed by WSRR Studio in place of the nameorder
    Ontology commentCommentPurely a comment.Optional
    Ontology prefixPrefixUsed to prefix all the generated configuration files to separate them from other configuration items.order
    Target Configuration ProjectTarget configuration projectProject where the model will be created.CafeAndBakerScenario
  5. Save the file regularly in case goes wrong: Click File => Save.
    Figure 1. Diagram of business models and their relationships
    Diagram of business models and their relationships
  6. Begin drawing the model on the canvas: Drag the Class icon from the palette on the right (or click once on the icon and again on the canvas), and then type the class name to create the six classes shown in Figure 1, as shown below in Figure 2:
    Figure 2. Creating a new class
    Creating a new class
  7. Connect the classes: Click on Generalization on the palette, and then drag from the child class to the parent class. Repeat this for all the child classes, as shown in Figure 1 by the arrows with triangular arrowheads.  Ignore the arrow from FoodOrder to BoxOrder.
  8. Specify the attributes for the classes: Mouse over a class to open up another palette and click the leftmost option Add Attribute, then type the name of attribute you want to add. Follow this procedure for all attributes in the diagram. Don't worry about attribute types for now.
  9. Create enumeration types: Before you specify the types of the attributes in the previous step, you must define enumerations.  Expand Models, then right-click <<BusinessModelPackage>> OrderModel and click Add UML => Enumeration. Type the name of the enumeration, in this case Size, and press Enter.
  10. Right-click the Enumerationand select Add UML => Enumeration Literal. Type the name of literal, in this case Small.  Repeat for Medium and Large. Now create the following other enumerations, as shown in Figure 3:
    EnumerationEnumeration Literals
    Figure 3. Enumerations and enumeration literals in WSRR Configuration Project Explorer view
    Enumerations and enumeration literals in the WSRR Configuration Project Explorer view
  11. Specify attributes types and cardinality: Specify several properties of one attribute, and then repeat that step for all attributes. Click on <<BusinessModelProperty>> DateRequired on the Order class and select the Properties view from the tabbed view at the bottom. Ensure that the Properties view is showing the General tab (as shown in Figure 4 below).
  12. Specify the type and multiplicity (cardinality): Click Select type, type date in the search box, select date (not dateTime), and click OK.
  13. Since Multiplicity is to be a required field, ensure that it is set to 1. Repeat for the following properties. DateRequired is included again as an example.
    ClassProperty nameTypeMultiplicity
    OrderQuantityinteger (XSDDataTypes)1
    FoodOrderUnitPricefloat (XSDDataTypes)1
    BoxOrderSizeSize (OrderModel)1
    DoughnutTypeType (OrderModel)1
    DoughnutFlavorFlavor (OrderModel)1
    DoughnutCoatingIcing (OrderModel)1
    PastyFillingstring (XSDDataTypes)1
    Iced BunIcingIcing (OrderModel)1
    Figure 4. General tab of the Properties view
    General tab of the Properties view
  14. Specify detail view and collection view visibility: As before, specify the visibility for one attribute as an example and then repeat for the rest. With the Class diagram still open, click <<BusinessModelProperty>> DateRequired: date.  In the Properties view, open the Stereotypes tab as shown in Figure 5 and at the bottom, check the Stereotypes Properties table, which has several properties:
    collectionViewIf set to true, attribute will be included in the generated collection view
    commentthis is a comment which is included in the generated OWL file but never used in WSRR
    defaultValueas the name suggests, a default value for the attribute
    detailViewif set to true the attribute is displayed on the detail view for instances of the business model
    IDthe id is used to link two or more attributes (across classes) so that they are the same in the generated OWL. Normally leave this blank, but specify the same value for all attributes that you wish to link.  For example the two classes, IcedBun and Doughnut both have an attribute Icing, as this is the same type in both classes then we can set the ID as Icing, for both attributes, also setting the type the same for both attributes. This allows both attributes to have the same name and leads to only one shared data type in the OWL.
    labelthis is a label for the attribute. Attribute names are restricted, in terms of use of spaces, etc, so if you need to specify a less restrictive name then use this property.  By manual editing of the generated OWL file, it is possible to specify labels in alternative languages, but this only recommended for expert users.
  15. For <<BusinessModelProperty>> DateRequired : date, specify collectionView as true, detailView as true, and label as Date Required. Repeat as shown below:
    ClassProperty namecollectionViewdetailViewlabelID
    OrderDateRequiredTrueTrueDate Required
    FoodOrderUnitPriceFalseTrueUnit Price
    Figure 5. Stereotypes tab of the Properties view
    Stereotypes tab of the Properties view
  16. Specify the relationship between FoodOrder and BoxOrder: Every food order must have a box order before it can be shipped. This is modeled by connecting FoodOrders to BoxOrders with a directed association, resulting in a relationship in WSRR. Click the small right-facing arrow next to Association on the palette on the right, then click Directed Association.
  17. Click FoodOrder and drag to BoxOrder, then type the name of the relationship, such a BoxOrder, to specify a relationship from FoodOrder to an object of type BoxOrder.
  18. From the Properties view, similarly to the attributes, specify the multiplicity (for the BoxOrder side) as 0..1, and on the Stereotypes tab, set the label as Box Order.
  19. Ensure your diagram is the same as in Figure 1 and save the model: Click File => Save. The business model is now fully modeled and ready to generate a WSRR configuration.
  20. Right-click Models and click Generate All WSRR Artifacts. After a short wait you should see a success message.

Configuring the user interface -- overview

The WSRR UI is highly customizable. Using a series of XML files, you can control almost all aspects of the UI and tailor the user experience according to the person's role in the organization. WSRR uses seven different XML definition files:

The perspective definition is the top-level configuration object.  It ties together all the other configuration files. The WSRR UI has several perspectives, and you can only use one at a time.  Use the drop-down box at the top, to the right of the browser window, to set the current perspective.  The perspective file specifies the Menu Bar file, Navigation Tree file, and home page to use, and the mappings of detail view definitions to types.
Menu bar
The menu bar structure is specified in the menu bar configuration file.
Navigation tree
If you are still using a navigation tree, the structure is specified in the navigation tree configuration file.
View query
View queries, used in the Menu Bar and Navigation Tree configuration files, are specified in view query files.
Detail view
Detail view definition files specify how the data and metadata associated with an object stored in WSRR are displayed.
Collection view
Collection view definition files specify how lists of objects are displayed, including which properties are displayed in columns, whether they can be sorted, and so on.
Home page
The home page is the front page you see when you log in to WSRR. The home page definition file specifies the functionality present on that page.

Figure 6 shows the hierarchy representing how the different configuration files relate to one another:

Figure 6. UI Configuration definitions and their relationships
UI Configuration definitions and their relationships.

For each model in an individual WSRR Configuration Project in WSRR Studio, a whole set of UI configuration files, described above, is generated.  If you want the UI configurations to be in the same perspective, you must merge them manually.

Customizing Detail View definitions

When any object is WSRR is displayed, it uses a Detail View definition to determine what data to display and how to display it.  A Detail View definition is an XML file that conforms to the DetailViewDefinition XSD schema in the file system where WSRR was installed (for example, C:\Program Files\IBM\WebSphere\ServiceRegistry\admin\schemas\DetailViewDefinition.xsd). By default, a detail view is made up of several tabs, including: Details, Impact Analysis, Governance, Policy, and Activity. Only the detail tab can be customized, but you can select whether the other tabs are visible.

For this scenario, you need to define Detail View definitions for each of the bottom-level objects, such as Box Order, Doughnut, Pasty, and Iced Bun. They are auto-generated, but you must do some editing to prepare them for use:

  1. Open the Detail View definition for Doughnut.
  2. Expand Configuration Profile Files => Web UI Configuration => Detail Views and double-click orderDoughnutDetailView. When the file opens the default view is Design. Switch to the Source tab at the bottom of the main view.

The first part of this file that matters is <definition:tab-definition tab-name="details">.  As the tag suggests this defines the Details tab of the Detail View, where the name attribute is used internally to represent this tab. From herein when describing the XML tags the namespace will not be shown, for example, tab-definition, not definition:tab-definition.

Tab-title-message defines the name as Details from the default Resource Bundle.  Resource Bundles are a Java concept that contain locale-specific objects. For more information relating to Resource Bundles, search the internet for java.util.ResourceBundle.

The main section of the Details tab is the General Properties, denoted by the general-properties tags.  The first tag within these tags is heading-message which specifies the heading for the section, by default this is General Properties.

Each property is then specified by a property tag. Property-name is the name of the property, not how it is displayed. For modeled properties such as Flavor, the property-name specified in the detail view must be in the form prefix_propertyname, so for flavor, it would be order_flavor. This separates the property from any user-defined properties that may have the same name. The property-messages tag is concerned with what is displayed, with property-message specifying the text to use, and field-help-message specifying the hover-help. The generated file doesn't specify the resource bundle for properties like name and namespace, as there are already messages in all the supported locales for these properties, but it does specify a resource-bundle for the modeled properties. The resource bundle is a text file with key value pairs, saved within a JAR file.

For WSRR V6.3: In WSRR Studio, these JARs will open in the OS’s associated application for files of type JAR. Ensure that the association is with something like WinZip:

  1. Open the Resource Bundle.
  2. Expand Configuration Profile Files => Web UI Configuration => Resource JARs.  Then double-click orderResource and open the file with an editor that can handle Unix-style end-of-line characters, such as Microsoft WordPad.

For WSRR V7: The nature of Resource JARs is hidden from the user, and WSRR Studio opens the properties file for the user as if it were in a simple folder:

  1. Open the Resource Bundle.
  2. Expand Configuration Profile Files => Web UI Configuration => Resource JARs.  Then double-click orderResource to open the properties file in WSRR Studio.

Each class, such as Doughnut, has a section for its Detail View message and its Collection View messages.  Message names are in the pattern for the property name and for the hover help. In WSRR V6.3, any changes made now will be overwritten the next time WSRR Artifacts are regenerated.

Returning to the detail view, after general-properties is additional-properties, in contrast to what its name suggests, refers to the Links section on the right of the Detail View page. It is optional and does not include the other sections below Links.

After additional-properties is remaining-properties, which defines what is displayed as Additional Properties.  By default, it is a collapsed twisty of all other properties, both modeled and user-defined, that are set for the object. It can be removed if required, or set to be initially expanded.

The next section is Relationships, which lists all the relationships from this object and provides links to the targets. The generated relationships tags include tags that exclude relationships: predecessors and template.  In this example of Doughnut, it explicitly specifies the relationship from Doughnut to BoxOrder, letting you specify more detailed messages and hover help. The relationship would still have been displayed here without the specific reference.

The classifications tag specifies where on the page to list the classifications applied to the given object.

That is the end of the generated Details tab.  The remaining tags specify details for the other tabs on the detail view.  See the information center for more on the detail tab and the other tabs.

For this scenario, you don't need properties: description, namespace, and version for any of the modeled objects.  Edit each of the Detail View definitions and remove these from the General Properties.  The order in which the properties are displayed can be changed by reordering the properties in the Detail View definition. It is unlikely that you will want the remaining properties to be displayed or many of the extra tabs. Delete these as needed. Deleting the tab-definition tags is sufficient to remove them from the detail view. Make sure that you leave the Governance tab.

Customizing Collection View definitions

The Collection View definition specifies how a list of objects of an individual primary type is displayed in WSRR. For example, instances of the Doughnut business model are listed according to the orderDoughnutCollectionView file.  A Collection View definition file is an XML file that must conform to the CollectionViewDefinition XSD schema. There are two essential parts to the Collection View definition; a list of properties that are represented as columns and a list of the buttons which are displayed across the top of the results table.

In the Collection View, the list of columns is defined within the column-definitions tags.  Each column is defined by a pair of column-definition tags with heading-message and property-name tags inside denoting the column heading and the property to be displayed respectively.

After column-definitions is button-definitions. Buttons are defined by a pair of button-definition tags, enclosing button-message,button-action and (optionally) model- reference tags. Button-message defines the texts that appears in the button and button-action specifies what should occur when the button is clicked.  The options for button action are finite and include createGenericObject and deleteItems.  More can be found on these options in the information center. Model-reference is only used when the action is createGenericObject and specifies the type of modeled object to create.

Each of the classes defined in our business model has a Collection View definition generated for it.  This includes name, graph, namespace, version and description out-of- the-box and whichever modeled properties have had the stereotyped property: collectionView set to true.  As with the detail view definitions; namespace, version and description are not required, nor is graph, so please remove these from the Collection View definitions for Doughnut, Pasty, IcedBun, BoxOrder and FoodOrder.  There is no need to change Order as we don't need its Collection View at all.  You could, optionally, delete it and remove its entry from the Perspective Definition.

  1. Find the Collection View definitions: Expand CafeAndBakerScenario => Configuration Profile Files => Web UI Configuration => Collection Views.  The generated Collection Views begins with our specified prefix: order.

Creating life cycle and classification

Life cycles are a means of controlling the governance of objects in the WSRR.  Specified in the State Adaptive Choreography Language (SACL), life cycles are a set of states and the transitions between those states.  Transitions can be manual or automatic (such that when a state is reached the transition occurs immediately and the object moves into the next state).  Life cycles are analogous to the concept of state machines and using WSRR Studio are defined in UML.

In WSRR there can only be one life cycle configuration loaded at any one time.  When you create a new life cycle in WSRR Studio, what actually happens is that you create a new composite life cycle and when you initially govern an object you select the composite life cycle desired.  As a consequence of this, once you define your own composite lifecycle all the GEP life cycles are subsequently generated in the configuration profile. To prevent this:

  1. Delete all the LifecycleStateMachines from within <<LifecycleModel>>LifecycleDefinition.
  2. Create a new life cycle model: Expand CafeAndBakerScenario, right-click Models, and select Create WSRR Lifecycle. In the resulting wizard enter:
    WSRR V6.3 fieldWSRR V7 fieldDescriptionInput
    State machine nameNameName representing the life cycle, used in WSRR Studio and in WSRR when initiating the life cycle.OrderLifeCycle
    State machine labelLabelUsed by WSRR only when referring to the life cycle’s classification system from a configuration perspective.Order Life Cycle
    State machine viewLabelWeb UI display name Used in the generated WSRR UI’s Menu Bar to refer to the life cycle.Order Life Cycle
    State machine commentCommentPurely a commentOptional
    State machine viewCommentWeb UI descriptionDescription of the life cycle used in the Web UIOptional
    Target Configuration ProjectTarget configuration projectProject where the model will be created.CafeAndBakerScenario
  3. Create four new states on the canvas: Drag State from the Palette on the right side on to the canvas four times.
  4. Rename all the states, including the Initial and Final states.
  5. Click on the automatically assigned name and press F2 (or just type) to rename each state.
  6. With a state selected, open the Properties view at the bottom of the screen and navigate to the Stereotypes tab.  From here you can set the label.
  7. From InitialState to FinalState, rename all states and apply their labels:
    Original NameNew NameLabel
    InitialStateCandidateOrderCandidate Order
    State1SubmittedOrderSubmitted Order
    State2SubscribedOrderSubscribed Order
    State3OrderReadyOrder ready
    State4OrderDispatchedOrder Dispatched
    FinalStateOrderCompletedOrder Completed
  8. Link the states with transitions. To define a transition, click Transition (in the Palette), then drag from the source state to the target state.  Perform this for five transitions between the states in the order shown in the above table. Don't worry about naming the transitions yet.
  9. Arrange the diagram: Right-click and select Arrange All.
  10. The life cycle is now defined but the triggers for the transitions are not, and the default for them is automatic. In this case, automatic is not the desired behavior, so you need to define the trigger for the transitions: Right-click a transition and select Add UML => Trigger => Signal Event. A new menu opens.
  11. Select Create Signal Event, which causes another new menu to appear.
  12. Select Create Signal. Repeat this for all the transitions starting from the bottom and working up towards the Order Completed state.
  13. Rename the signals and apply labels to them.  If there is no label present, WSRR Studio will use the name when generating the configuration files, but labels are more flexible.
  14. Define labels for and rename the Signals: Expand CafeAndBrokerScenario => Models => <<LifecycleModel>> LifecycleDefinition and click <<LifecycleSignal>> Signal1.
  15. Open the properties view at the bottom of the screen. From the General tab you can rename the signal, and from Stereotypes you can edit the label. Set the following labels and names for all the Signals:
    Signal nameLabelNew name
    Signal1Submit OrderSubmit
    Signal2Subscribe to OrderSubscribe
    Signal3Fulfill OrderFulfill
    Signal4Dispatch OrderDispatch
    Signal5Pay for OrderPay
  16. This finished life cycle should look like Figure 7. Save the life cycle: Click File => Save.
    Figure 7. Completed life cycle diagram.
    Completed life cycle diagram
  17. The life cycle is now finished and ready for WSRR configuration generation. Right-click Models and click Generate All WSRR Artifacts. This time, the success message will also say that it hasn't overwritten the manual changes to the view definition files. Instead, files were generated with .gen in their filename and displayed with (Generated) after the name in the Explorer. Had you made changes to the model which needed to be included in the manually modified files, then it would be up to you to manually merge the files and delete the .gen files.

Creating View Query and Menu Bar definitions

WSRR V6.3 navigation around the UI is done with the Menu Bar, which consists of several optionally nested menu items. A menu item can be a link that you click to perform an action, or it can reference a View Query to display a subset of items in the registry.  Each Menu Bar definition file defines one Menu Bar. The Menu Bar definition is specified in XML and must conform to the MenuBarDefinition XSD schema.

A View Query definition defines a query to run and a collection view to use to display the results.  There are several different mechanisms for specifying the query; from using XML tags to specifying actual XPATH. Each model in the Configuration Project will result in a separate ViewQuery file being generated and a separate Menu Bar definition. The View Query definition is specified in XML and must conform to the ViewQueryDefinitionSet XSD schema.

  1. Open the Menu Bar definition for the OrderModel business model: Navigate to CafeAndBakerScenario => Configuration Profile Files => Web UI Configuration => Menu Bars and double-click orderMenuBar.

Menu Bar definitions are straightforward. Within one pair of menu-bar tags there is one (and only one) pair of menu-item tags which forms the root of the menu-bar. Within this first pair of menu-item tags there are any number of menu-item tags which can be nested within other menu-item tags to represent sub-menus.  The first menu-item within the menu-bar doesn't actually represent an entry in the menu, unlike all other menu-item tags.

Each menu-item must have an id and a message-key attribute.  The id is a unique string used to identify the menu-item.  The message-key allows the localized text to be displayed in the menu to be specified. Optionally, menu-items can have resource-bundle-name, specifying the resource bundle containing the message-key and view-query-id that specifies the query to execute when menu-item is selected.  Other optional attributes also exist -- for more information, see the information center.

  1. Open the View Query definition file for the OrderModel business model: Navigate to CafeAndBakerScenario => Configuration Profile Files => Web UI Configuration => View Queries and double-click orderViewQuery.

    Within a pair of ViewQueryDefinitionSet tags is a pair of QueryDefinitions tags. Within these are one or more pairs of Query tags.  There is one query tag per defined query.  Queries can be specified in several different ways.  All the WSRR Studio-generated Query definitions follow the same pattern with each query returning all objects with a given classification.  For example, the orderViewQuery query with name showorderIcedBuns, which will return all IcedBun objects is defined as below:

    Excerpt from generated View Query definition
    <set:Query id="showorderIcedBuns">

To see the complete list of all the ways of defining view queries see the information center. The UI configuration files generated are a best guess, and cannot be expected to be exactly what is wanted by the end user.  For this example we will create new entries in the menu bar which take the user straight to the creation wizard for each of the food orders, and assuming the menu bar is for café users and not for the bakers, move menu bar entries which show existing orders in various life cycle states to the menu for the business models.

  1. Open the Menu Bar definition for the OrderModel business model: Navigate to CafeAndBakerScenario => Configuration Profile Files => Web UI Configuration => Menu Bars and double-click orderMenuBar.
  2. Around line 11, find a menu-item with id view. Immediately before this line, insert a new menu-item with id create and message-key You can use Control and Space to autocomplete the tags. It should look like this:
    <definition:menu-item id="create" message-key="">
  3. Inside these tags, create three new menu-item tags with the following details.

    It should now look like this:

    <definition:menu-item id="create" message-key="">
    <definition:menu-item id="create.doughnut"
    <definition:menu-item id="create.icedbun" 
    <definition:menu-item id="create.pasty" 

    Use messages from existing resource bundles here to avoid having to define your own. WSRR Studio overwrites any changes to the generated resource bundle. The life cycle menu bar entries are in a different menu bar configuration file from the one you've just edited, because they have different prefixes, and prefixes must be unique. Copy over the menu bar definition from the life cycle menu bar to the business model one.

  4. Open the LM64 Menu bar configuration file: Navigate to CafeAndBakerScenario => Configuration Profile Files => Web UI Configuration => Menu Bars and double-click on LM63Menu.
  5. Look for the line: <definition:menu-item id="menu.LM63.OrderLifeCycle" message-key="menu.LM63.OrderLifeCycle" resource-bundle-name="LM63Resource" view-query-id="showLM63OrderLifeCycles"> and copy everything from this line to </definition:menu-item> inclusively.
  6. You should still have the order menu bar definition open. Find the line <definition:menu-item id="menubar_help" message-key=""> and paste in the configuration, you just copied, immediately before it.
  7. Save the file: Click File => Save.

Customizing the Home Page definition

The home page definition defines the panels visible on the home page.  There are five different types of panel; business objects panel, saved search panel, object collection links, load document panel and browse by classification panel.  Home page configurations are defined in XML which conforms to the HomePageDefinition XSD schema.  WSRR Studio does not generate configuration for the home page, however generated business models will show in the business objects panel. For more on home page definitions, see the information center.

Customizing the Perspective definition

The WSRR UI supports the concept of perspectives.  A perspective represents a collection of different views, which allow for different perspectives to each provide a different view of the same data. Perspective definition files sit at the top of the hierarchy of UI configuration files.  It is with the perspective definition file that all the other UI configuration files are tied together. Perspective definitions are specified in  XML files conforming to the PerspectiveDefinition XSD schema.

WSRR Studio generates a perspective definition file for each model (or prefix) in the Configuration Project.  It automatically creates entries specifying that the generated detail views, menu bar and collection views are to be used.  Inside a pair of perspective-definition tags are tags which specify all aspects of the perspective.  Perspective- definition has two attributes; weight, which helps to define the ordering of the perspectives in the perspective selection drop-down menu and perspective-definition-name which is the name shown for the perspective in the perspective selection drop-down menu. Here are the relevant sections of the perspective-definition:

Tag nameDescription
menu-bar-nameSpecifies menu-bar configuration to use
home-page-nameSpecifies home-page configuration to use
detail-view-mappingsContains view-mapping tags, each pairing a detail-view-definition with a display-type.
collection-view-mappingsContains view-mapping tags, each pairing a collection-view-definition with a display-type.

There are other sections to the perspective-definition configuration file and these are detailed in the information center.


You have now created a fully customized UI for WSRR that will make it much easier for users to interact with it. You have created business models, defined a life cycle, customized View Definitions and Collection Views for the business models, and defined menu bar entries to access them. You can do even more customization by creating custom buttons and themes -- for more information, see the information center.

  1. To see the results of the customization, export what you have and load it into WSRR: Click File => Export. Expand WebSphere Service Registry and Repository (WSRR) and select WSRR Configuration Profile.
  2. Click Next. Ensure that CafeAndBakerScenario is selected for Configuration Project.  Enter a directory of your choice in Target Directory (or navigate to it by clicking Browse).
  3. Click Finish. WSRR Studio automatically generates the WSRR artifacts before exporting, which can lead to errors or warnings at the point of completion.  If you have warnings, simply click Finish. For errors, you must click Cancel.
  4. Import the Configuration Profile into WSRR and activate it: Browse to the URL for your WSRR deployment, such as http://myserver:9080/ServiceRegistry. Log in if required.
  5. From the perspective drop-down, select Configuration. Once loaded, go to the menu bar and click Manage Profiles => Configuration Profiles.
  6. Click Load Configuration Profile.
  7. Click Browse and navigate to the zip file exported from WSRR Studio.  Enter a name for the profile where it says Provide a Profile configuration item name, and click Finish.
  8. Once loaded, select the check box next to the profile just loaded, and then click Make Active.
  9. Switch to the orderAdmin perspective: From the perspective drop-down, select orderAdmin.

Check out the UI that you have just created.  Try out the menu and create a few orders, then govern your orders and transition them. You should then be able to use the Order Life Cycle menu to view the objects at each life cycle stage.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Customising the WebSphere Service Registry and Repository user interface