Unified Inventory Management: Building Domain Support. An Oracle White Paper September 2014

Transcription

1 Unified Inventory Management: Building Domain Support An Oracle White Paper September 2014

2 UIM: Building Domain Support Table of Contents Contents Introduction... 3 Defining Domains in UIM... 3 Technology Packs... 3 Designing and Building Technology Packs... 4 Planning and Domain Analysis... 4 Building Configuration Artifacts in Design Studio... 6 Equipment Specifications... 6 Custom Object Specifications... 7 Logical Device Specifications and Logical Device Account Specifications... 7 Telephone Number Specifications and Rule Set Extension Points.. 8 Service Specifications and Service Configuration Specifications Characteristics Managing Cartridges Building Web Services Building Customized Web Pages Localizing Text Using Oracle Technology Packs Unified Inventory Management: Building Domain Support Page 2

3 UIM: Building Domain Support INTRODUCTION This white paper explores concepts and recommended practices for the development of Oracle Communications Unified Inventory Management (UIM) technology packs. It has been written for systems integrators and service provider IT staff responsible for configuring UIM to fit provider specific needs. An example of a mobility technology pack is utilized to illustrate the process. This paper assumes that you have a basic understanding of UIM and Oracle Communications Design Studio as well as basic data modeling concepts. For additional information on topics covered in this white paper, refer to UIM Concepts (formerly known as Understanding UIM), UIM Studio Help, UIM Developer s Guide, and UIM Model Overview. Technology packs are utilized to tailor Oracle Communications Unified Inventory Management to support specific scenarios. DEFINING DOMAINS IN UIM One of the key tenets of Oracle Communications is delivering a highly modular, extensible, scalable communications suite of software capabilities that can be assembled into meaningful business applications and products and that look, feel, configure, work, and extend as if they came from a single mind. UIM is a very flexible application based on a generic model that may be specialized to support the objects and behaviors intrinsic to almost any infocom domain. Each of its functional managers supports certain aspects of resource or service management in a domain independent manner, but each can have its behavior modified via configuration that is specific to a domain such as VoIP, Cable TV, or Metro Ethernet. Technology Packs A UIM technology pack is the aggregation of configuration artifacts that together extend or specialize UIM to support a specific area. A technology pack may be fairly simplistic, but it can also be a complex collection of components (information models, structures, behaviors, interfaces, data, software modules, and user experiences) that embody closely related capabilities and solve simple to large complex business problems. The most common context is the packaging of the design time configuration for a particular service or network/resource domain. Domain technology packs allow a designer to define configurations relevant to a domain and deploy the complete set in various UIM run time instances. This may be done for development, test, and production. Technology packs are primarily realized as cartridges in Design Studio. A technology pack can encompass one or more cartridges, each containing specifications, characteristics, or rule sets; together they define the UIM catalog for the domain. Other types of domain specific artifacts are less commonly used, but they may also be part of the set. Unified Inventory Management: Building Domain Support Page 3

4 Configuring UIM to represent a domain may involve any or all of these. De sign Stu dio for UIM Spe cifica tion Cha ra cte ristic All of t hese are commonly used to adapt UIM to a domain the y define objects, relationships and intrinsic beha viors Eclip se Ja va Pe rspe ctive or othe r de velo pment en vi ron ment Occasionally also needed to support domain specific operations W e b de ve lopme nt e nvironme nt or HTML/text editor Rule Se t W eb Service W SDL Adapters Custom W eb Page Ca rtridge JAR file HTML te xt file JAR file Rarely used t o provide domain specific UI Localization File text file Figure 1: UIM Configuration Artifacts, Packages, and Tools A service provider or systems integrator may use Design Studio with the UIM plug in to create cartridges from scratch, following the guidelines and examples in this white paper. Oracle also provides small sample artifacts that can be reviewed to offer useful techniques and approaches for your own work. It is useful to understand the entire process of building domain support in UIM, even if you follow the simplified approach leveraging commercial technology packs built by Oracle, described later in this paper. DESIGNING AND BUILDING TECHNOLOGY PACKS When you want to build UIM s capabilities to support a new domain by developing a technology pack, several leading practices and guidelines should be followed. The creation of a technology pack includes two basic tasks: planning and domain analysis, and building configuration artifacts. Planning and Domain Analysis In planning your project, it is important to define boundaries of the target domain and what is important to your business about the domain. To guide your thinking, you may want to answer the following questions: What industry standards are relevant to the domain? Which technology architecture or network vendor specific variations are relevant in your environment? How does the target domain relate to other domains that the business has deployed or plans to deploy? As part of the domain analysis, it is helpful to start with a high level scenario diagram and then build any of the following artifacts that you need: Service and resource model Use cases Activity diagram Unified Inventory Management: Building Domain Support Page 4

5 List of specifications List of behavior rules Diagramming tools such as Visio and data modeling tools such as Rational are often beneficial in planning and validating the artifacts to be later represented in Design Studio. The scenario used to illustrate the process is a simple one from the mobile domain, viewed from the perspective of service provisioning. The examples create a mobile telephone service with voic and wireless Internet access. Mobile Service Provider Context Application clients Voice Mail Se rve r E mail, clients Mobile Equipment IC Card Um interface HLR E Ma il Se rver Inte rne t E mail, web, messaging & other clients App lication Server W AP Ga te way PSTN Mobile Loca tion Figure 2: Mobile Service Domain Context Se rvice Provider Resources For Mobile Service TelephoneNumber.mobile CustomObject.SIM LogicalDevice.Voic LogicalDevice.WAPServer 1. Characteristic.SIMID RulesetExtPt.mobile Equipment.MobileHandset LogicalDeviceAccount.Voic LogicalDeviceAccount.WAP 1. TELEPHONE_NUMBER_FORMATTING (ruleset) 2. TelephoneNumberManager_CreateTelephoneNumbers (Point) 1. Characteristic.Password 1. Characteristic.WAPService 10MB Unlimited Figure 3: Resources for Mobile Service Mobile Phone Service Model ServiceConfigSpec.Mobile CustomObject.SIM TelephoneNumber.mobile LogicalDeviceAccount.Voic LogicalDeviceAccount.WAP Figure 4: Mobile Phone Service Model Unified Inventory Management: Building Domain Support Page 5

6 Cartridges are created in Design Studio and are loaded into UIM. Building Configuration Artifacts in Design Studio To define UIM capabilities, objects such as specifications, characteristics, rule sets, and extended code are built using Design Studio for UIM. These are organized into cartridges, which can include other cartridges, but they cannot include Web services. Cartridges are created in Design Studio and are loaded into UIM, where the specifications and rules they contain are used to direct the behavior of the runtime application. For more information on creating cartridges, refer to UIM Concepts and Design Studio Help. Because specifications and characteristics must be uniquely named in a Design Studio workspace and in a UIM database, you should adopt a careful and systematic naming convention. If you are not careful about naming, you run the risk of overwriting an existing specification or characteristic or of having one of your specifications or characteristics overwritten when a technology pack is installed. Unique names are required in Design Studio as long as you are working in the same workspace. Additionally, when you design technology packs and cartridges, you should separate artifacts into cartridges based on what might be reused in the future. When naming a cartridge for a technology pack, Oracle recommends you follow a format similar to xyz_mobility. Each item created within the cartridges should follow standardized and descriptive naming conventions. For example, a SIM card modeled as a custom object should be given a name similar to CustomObject.SIM. Creating inventory resources and then creating services that utilize these resources can be the most efficient process in creating cartridges. Equipment Specifications Equipment specifications are used to represent physical items. In the mobility use case, equipment specifications are utilized to model a mobile handset. However, equipment specifications are commonly used for items that require a hierarchy such as racks, shelves, and cards. A handset could also be modeled as a custom object. In the mobility use case, the handset is related to the SIM card, and this relationship is established when the custom object is created. Figure 5 is an illustration of the handset Equipment specification. Figure 5: Equipment Specification Unified Inventory Management: Building Domain Support Page 6

7 Custom Object Specifications Custom Object specifications allow you to build your own custom objects in UIM to represent entities that do not fit into any of the predefined categories. This allows you to customize solutions to solve business issues. For example, you can create a custom object to define a protocol or policy such as quality of service standards or static routes. Figure 6 is an illustration of the SIM card Custom Object specification. Figure 6: Custom Object Specification Logical Device Specifications and Logical Device Account Specifications A logical device represents a functional view of a set of resources. The logical device itself is not physical, but it is often supported by one or more physical resources that support it and act together logically to perform one or more functions. In the mobility use case, the Logical Device specification is used to model the voic server and the WAP server. A Logical Device configuration specification contains information about how the device is realized. In the mobility use case, there are no configuration specifications but there are related specifications. These related specifications are the logical device accounts for the voic server and the WAP server. These can be associated when the Logical Device and Logical Device Account specifications are created. Figure 7 is an illustration of the Logical Device specification for the voic server with the related Equipment specification. Unified Inventory Management: Building Domain Support Page 7

8 Figure 7: Logical Device Specification Logical device accounts are a special type of network address that are hosted or managed by a logical device. For a service provider, a logical device account could be a management account, such as a login name, for configuring a logical device. You use Logical Device Account specifications to define these accounts in your inventory. A Logical Device Account specification represents a functional view of a set of resources. The logical device itself is not physical, but it is capable of being supported by one or more physical resources that act together logically to perform one or more functions. In the mobility use case, the Logical Device Account specification is used to model accounts related to the voic server and the WAP server. In the mobility use case, characteristics are added and logical devices are associated. Figure 8 is an illustration of the Logical Device Account specification for the voic server account with the related Logical Device specification. Figure 8: Logical Device Account Specification A rule set contains application business logic, and an extension point identifies a core business process that can be customized with a rule set. Telephone Number Specifications and Rule Set Extension Points You use Telephone Number specifications to define the types of telephone numbers that your inventory includes and how they are managed in the business process. A Telephone Number specification is a blueprint for the various kinds of telephone numbers you might use. In addition to the standard aspects of a specification, you need to define how telephone numbers based on the specification are formatted for display and storage. After a Telephone Number specification is created, rule sets can be applied to the specification. In the mobility use case, a rule set is associated to the Telephone Number specification to establish a telephone number format. Unified Inventory Management: Building Domain Support Page 8

9 In the mobility use case, the Telephone Format rule set is associated to the Telephone Number specification by utilizing a rule set extension point as illustrated in Figure 9. The Telephone Number format is an example of a base rule set that defines the format of a telephone number when the instance is created in UIM. Figure 9: Telephone Number Specification Rule sets are used to control actions on certain entities at certain times and conditions. Rule sets provide a highly flexible way to interact with entities at certain times. The following is an example of a rule: Make the telephone number field s edit mask to be ### ### #### at creation time for the telephone numbers based on the North American Telephone Number specification. You use rule sets to extend and customize UIM by associating an extension point to a rule set. Rule sets provide the capability to modify the business logic at run time. Figure 10 illustrates the Telephone Format rule set from the base technology pack that is utilized by the mobility use case. No changes were required because the format that is defined by the rule set is what is used by the mobility use case. For additional information on rule sets, refer to UIM Developer s Guide. Figure 10: Telephone Format Rule Set To utilize a rule set, an extension point must be created. The extension point connects the specification to the rule set and can then be associated to the desired specification. Within the Ruleset Extension Point specification, you associate a rule set, Point, and Placement. Figure 11 is an illustration of an extension point. Unified Inventory Management: Building Domain Support Page 9

10 Figure 11: Rule Set Extension Point Specification Service configurations provide a versioning capability that enables the management of changes to a service over time. Service Specifications and Service Configuration Specifications Because a Service specification requires a Service Configuration specification, the Service Configuration specification should be created first. The Service Configuration specification captures the details about the resources used by the service. Because these details can change frequently, Service configurations provide a versioning capability that enables the management of the changes to a service over time. As the facts about a service change over time, new versions of the Service configuration can be created. When you define a Service Configuration specification in Design Studio, you determine the collection of resources that can be allocated to the service. You define these resources as configuration items. The configuration items can have characteristics that enable you to express details about the configuration. The configuration items can be arranged hierarchically. Figure 12 illustrates the Service Configuration specification with the selected configuration items. The specification allows each configuration item to define configuration item information, characteristics, layouts, and specification options. Within the specification options, all related resources are displayed for the selected configuration item. Figure 12: Service Configuration Specification Unified Inventory Management: Building Domain Support Page 10

11 After the Service Configuration specification has been created, the Service specification can be created; and then the Service Configuration specification can be associated. Figure 13 illustrates the Service specification in the mobility use case. Figure 13: Service Specification Characteristics Characteristics provide a means of storing specific items of information about an entity. In the mobility use case, characteristics are created for user name, password, WAP service, and SIM card part number. These are then utilized by the Custom Object specification, the Logical Device specifications, and various Logical Device Account specifications. There are four types of characteristics: text field, check box, calendar, and list. In the mobility use case, text field and list type characteristics are utilized. Figure 14 is an illustration of a text field characteristic. Figure 14: Creation of the Username Characteristic The second type of characteristic utilized in the mobility use case is a list. This characteristic is required to provide a selection for the type of WAP service provided by the logical device account that includes two values and is illustrated in Figure 15. Unified Inventory Management: Building Domain Support Page 11

12 Figure 15: Creating a Characteristic with a List Managing characteristics carefully is very important. Organizing all characteristics in a single cartridge can be helpful and may prevent the creation of a characteristic when a similar characteristic already exists. Managing Cartridges Before a cartridge is installed, it should be saved, cleaned, and then built. The order a cartridge is installed is very important. The current cartridge overwrites previously installed cartridges. Cartridges can be maintained between releases of UIM. If you have a cartridge built in a prior release, you must clean and rebuild the cartridge in the new version of Design Studio before it can be installed in the new version of UIM. As a general rule, you can install an upgraded cartridge as long as no instance data based on the original version has been created in UIM. You can reinstall a cartridge even when instance data exists as long as the cartridge contains no changes compared to the previous version. Installing a new version of a cartridge is also safe when the changes it contains are limited to adding new content. If instance data, based on the cartridge, has been created in UIM, and the cartridge includes non additive changes, however, issues can arise when you install an upgraded version of the cartridge. These kinds of changes are not recommended because they can interfere with existing content and with extensions and additions you may have. After the cartridges are complete, they should be saved, cleaned, and built in Design Studio. After your cartridges are completely built, you need to load them into UIM. To load the cartridge into UIM, you need to perform the following steps. 1. Log into UIM and select Setup in the Navbar section. 2. Select Cartridge Management. 3. Browse to locate the JAR file in the CartridgeBin folder under the project directory. 4. Select Install. Building Web Services Web services are Web APIs that can be accessed over a network, such as the Internet, and run a remote system hosting the requested services. Web Services are Unified Inventory Management: Building Domain Support Page 12

13 a key interface mechanism for UIM, allowing catalog and inventory information to be exposed to other applications in a Service Oriented Architecture (SOA). While many Web Services in the UIM environment will be domain agnostic, you may find it useful for your project to create domain specific Web Services that expose and allow manipulation of the objects you define using Design Studio. For more information about Web Services, refer to UIM Developer s Guide. Building Customized Web Pages UIM s browser based user interface is built on the Oracle ADF framework. You can extend the UI, which includes such things adding new pages or adding fields or new functionality to existing pages. While it is rarely necessary, you can use the provided UI toolkit to extend or modify the UIM user interface to have the components and flows you think are appropriate for a specific domain. For more information about customizing the user interface, refer to UIM Developer s Guide. Localizing Text Localization is the progress of changing a UI from the original language in which it was written to another language. UIM s UI framework supports this via the use of properties files that are used by the browser to drive the actual text displayed. This mechanism can also be used not to change from one natural language to another, but to replace standard or generic terminology with something domain specific. For more information about localization, refer to UIM Developer s Guide. USING ORACLE TECHNOLOGY PACKS An alternative approach to building domain support is to license one of the technology packs from Oracle s growing library. Each of these products leverages Oracle s domain expertise and expertise in implementing domain models using UIM. It is based on a documented best practices view of the target domain and is designed to include most of the elements that are useable by multiple service providers, leaving the scenario specific parts for project implementation. Starting your domain project with an Oracle technology pack saves time by leveraging a core framework around a domain that can then be extended to suit your company s or client s specific environment or perspective. Proje ct spe cific a rtifa ct s Ora cle Te chnology Pa ck Base cartridges UIM Core Figure 16: Technology Pack Hierarchy These technology packs are sold as products by Oracle and are fully documented and supported. They are designed to allow you to take advantage of future enhancements such as additional objects, richer object modeling, and additional behavioral rules. Unified Inventory Management: Building Domain Support Page 13

14 In some cases, you may find that the specifications found in a commercial technology pack are exactly what the business requires, and they may be used with no changes. However, this is typically not the case, and some tailoring is required. Each Oracle domain technology pack is designed with specific field adaptations in mind. By following the documented guidelines, you may extend and customize the artifacts to fit a specific scenario while minimizing the risk of rework when upgrading to a new version of the technology pack. Though each service provider and domain is unique, a typical life cycle would involve the following activities 1. License the Oracle technology pack for the desired domain, then download and install the cartridges in Design Studio for UIM. 2. Review the contents and make desired changes and additions, following the general guidelines in this white paper and in UIM Concepts, as well as any specific ones in the implementation guide for the technology pack. 3. You operate the UIM runtime to create inventory object instances based on the specifications in the technology pack as you have tailored it. 4. Later, you upgrade your technology pack, following the guidelines outlined in UIM Concepts to maximize compatibility with your field extensions. 5. Evaluate the impact on any existing technology packs. 6. Install the new version of the technology pack and make any required adjustments. 7. You operate the UIM runtime to create inventory object instances based on the updated, tailored technology pack. Unified Inventory Management: Building Domain Support Page 14

15 Overview: Building Domain Support Sept 2014 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Worldwide Inquiries: Phone: Fax: oracle.com Copyright 2014, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. 0310