SAP Blogs: enterprise portal roles

Showing posts with label enterprise portal roles. Show all posts

Monday, June 27

Save Costs, Time, and Efforts-install Business Packages

Some basic information about business packages is provided in this post, Business packages are predefined content developed by SAP or third-party vendors that serve particular business requirements.

Business packages are a collection of roles, worksets, pages, or iViews.

By installing a business package, you can save costs, time, and efforts incurred in

implementation. Because it is created by either SAP or third-party vendors, a business

package does not require much development This results in savings. No licensing is involved for importing a business package as long as the customer has purchased licenses for the portal and the backend with which the business package will be integrated.

Depending on the customer’s requirements, you can deploy whole business package, or part of it. You can integrate SAP content in the back end with business package. For example, if SAP Human Resources Application (HR), SAP Sales and Distribution (SD), and SAP Business Information Warehouse (BW) etc are already installed, you can install the business package and integrate with the back end to create transactions through the Web.

You can install three types of business packages:

• Business packages for specialists

• Business packages for managers

• Business packages for end users

A business package may consist of:

• Portal content objects The roles, worksets, pages, iViews, business objects, and

system objects.

• PAR files Portal Archive (PAR) files include Java applications or configuration files

required for content management, collaboration modules and UWL.

• Web Dynpro applications Web Dynpro applications can be run in web dynpro iView.

• Other objects Visual Composer PAR files , Transport packages,Repository

Manager PAR files etc…

Scalibility - Distribution of Software and Hardware Components and Sizing

This post will discuss aspects related to scalability. How to implement

scalibility by adopting techniques such as distribution of software and hardware components and sizing etc.

What Is Scalability?

What if the user population increases suddenly, the geographical distance of the users from the portal increases, number of portal functionality increases, the number of objects in the portal content directory increase or the size of data used in the KM application increase. The portal’s performance should not be affected by all these factors. The measure of its strength to withstand all these adversities is called scalability.

Scalability is important because by conducting appropriate load tests, you can determine aspects such as how many incoming HTTP requests can be processed in an hour, how many concurrent users can use the portal without significant performance degradation, and how many transactions can be executed in SAP R/3 from the portal.

How can scalability be implemented ?

This can be done by adding new hardware, such as servers, RAM, and hard disks, to maintain the portal’s performance at satisfactory levels with increasing loads. Also you can distribute portal components to different physical machines so that enough resources are available.

Sizing for Performance and Scalability

Sizing the various components is very important part of portal infrastructure design so that performance and scalability are good under heavy load conditions. Sizing determines the hard disk, memory, CPU, I/O, and network load requirements so that the response time is satisfactory.

Portal can be implemented in phases ranging over say 2 to 5 years. Is sizing is ok, performance will not suffer when system load increases due to increased users, increased workload activity, and other factors.

Sizing determines the success or failure of the project so it must be done ahead of the project start. But the factors which affect scalability and sizing are very dynamic in nature. They can increase of decrease during the implementation cycle also or after the portal has gone live, so sizing has to be kept in process. It is an ongoing activity and it part of portal maintenance.

Important - Proper sizing ensures that the portal performance does not suffer due to increased load.

The factors that influence sizing are database versions, portal software versions, customer-related factors and operating system versions.

customer-related factors can be the workload on the system, the nature of users in terms of the intensity of use of applications, number of users, geographical distribution of users,the amount of customizing involved.

Factors that can affect sizing are :

• Number of top-level menus in top-level navigation (TLN)

• Number of nodes in the detailed navigation iView

• Layout of the portal desktop and the portal framework page

• Number of iViews in the content area of the portal desktop

• Number of Java iViews that use Java Connector Remote Function Call (JCO RFC)

• Number of iViews that fetch data from SAP and non-SAP backend systems

• Custom navigation iViews and the programming model used to create those iViews

• Number of roles and groups created in the UME database

• Number of concurrent users using the portal

• Think time between two successive clicks

Etc…

It is very important that data about the above stated factors is gathered during the requirement gathering phase and thought is given to it well ahead. This will result in smooth operations after go live.

Sunday, June 26

What Is an Enterprise Portal?

While some argue that the portal is merely a website, others argue that it is more than that. An enterprise portal can be viewed as a means by which an organization tries to web-enable its applications, services, and information to its internal employees as well as its external partners. So, to that extent, enterprise portal software should be able to solve some of the complex challenges that arise out of web-enabling systems. To mention just a few examples, the problems could be associated to that of integrating the applications; providing a single sign-on to the end users so that they do not have to remember passwords for different backend applications; providing only the right information to the right user using authentication and authorization methods; ensuring application and network security; increasing usability by using techniques such as role-based personalization; providing content management features; and using KM functionality to integrate unstructured content such as file systems, database

systems, and websites.

INFO Good enterprise portal software should solve the challenges arising out of web-enabling systems and applications.

As you can see, a portal is a website, no doubt, but it is much more than just that. It is

the complexity that surrounds the portal that makes it so much more interesting and worth studying. SAP NetWeaver Portal is one such technology, an amazing one that aims to solve complex issues and tries to bring together the different SAP Business Suite solutions. In a way, it was born out of a need to provide a common user interface for various SAP products and to simplify access to end users using single sign-on. The next few chapters will unravel the potential of the SAP NetWeaver Portal to provide you with a greater understanding of what an enterprise portal is and what it can do for your organization. Portals come in different flavors, such as horizontal and vertical portals, employee portals, and manager portals. Portals can be classified into different categories based on the functionalities they provide and the user populations they serve.

Friday, March 18

SAP EP-Role maintenance

What are Portal Roles?

Technically speaking, a role is a hierarchy of folders. Folders in the hierarchy contain portal content. Portal content is iviews, pages, worksets etc. Portal roles can be assigned to user or a group of users. IN an organization there are various responsibilities assigned to various people. Based on their responsibility and daily work, they are assigned roles in portal. So a market analyst would have say role 1 and a marketing executive would have another role say role 2. The content of these roles will differ from each other. Roles are created in the portal based on the requirement of the company. As a portal user I will be able to see only that content of the portal whose role is assigned to me ID in portal. So only a single portal can cater to the needs to various department employees in an organization.

As already mentioned worksets are assigned to role. So to better understand the role concepts, we must be clear with what is a workset ?

Workset is a collection of applications or information which caters to a specific activity area like controlling and budgeting.

A role is based on the organizational structure. There are managers in the organization, there are delivery heads, there are marketing executives, there are business analysts. So corresponding these roles in the organization, there are roles defined in the enterprise portal.

Now a manager may have various responsibilities or activities to do in his/her job. These activities are modeled as worksets in the portal. Then these worksets are assigned to respective roles. Portal content is stored in portal content directory.

Maintaining portal content

Portal content is available in portal catalog and can be maintained in portal content studio. In the content administration role, choose Content Administration -> Portal Content. Enter general properties for the new role. Enter the folder for storing the new role in the Portal Catalog. Check all properties. The new role is created and is now visible in the Role Editor. Create the role hierarchy and add content objects (roles, worksets, pages, iViews) to the role as delta link. Change the properties in the Property Editor (optional) Objects are added to roles and worksets as delta links.

Delta Links

We can maintain relationship between portal content. In a relationship using the delta link, there are two objects, the source object and the target object. The properties of the source object are copied to the target object.

And if a change is made in the source object’s properties, they are reflected in the target object. But vice versa is not possible.

There are few points which should always be kept in my while creating roles in a portal. Please read below…

The basic purpose of enterprise portal is to provide a single point of access to all the people and teams involved in a business. So while creating roles, all of them should be kept in mind and then roles should be decided upon. Also long term goals of the company should be kept in mind while creating roles.

Analyse what all content will the portal hold to be displayed to its users. If it mainly contains static content like standalone websites and there is not going to be any more additions, roles are not so important there.

Based on roles, navigation structure within the portal is defined. But in some scenarios, the content available to a user (ie to his role) is very large. In such cases, search functionality using TREX and SAP KM gives faster results than using the portal roles navigation and reaching the desired content.

The best person to describe what all content should be available in a role is the one to whom that role in the organization belongs to.

As a good practice not more that 8 to 10 roles should be given to a portal user. Whatever content is needed by the user of that role should be wrapped up within 8 to 10 roles. Navigation becomes a real irritant if huge number of roles are present for that user.

While creating the content of the role, key consideration should be that the user navigates to the right content be reading the description of the portal content. So the description of portal content within a role should be consistent with each other rather than being consistent with the description of the actual content.

There should not be too many levels while designing the portal roles. It becomes a real problem if the portal role structure is deep say 5 levels deep. Also each level should not have more that 10 to 12 items.

The content available in a portal role should not be repeated in other roles. This may happen as per business needs but should be avoided as much as possible. The portal roles should be planned and designed for growth and change.

The number of portal roles should be as low as possible. This will reduce total cost of ownership of the portal.

Always keep in mind to arrange the content within a portal nicely. Avoid putting huge number of menu items. It becomes difficult for a end user to find out a specific content.

Few things like favorite-style iviews, portal eventing functionality come handy to simplify portal structures.

Out of all the content present in a role, some is used very frequently by the user and the user would want to see that first as soon as he/she navigates to his page. A well designed role should arrange the content in such a manner that most frequently content is displayed first.

Portal may use content from many resources. One such source is the SAP R/3 system. So a relationship between portal roles and the sap r/3 authorization roles should be established.

There are various ways portal roles and hence navigation can be designed. But the aim should be keep it simple. Avoid embedding roles within roles. You should bear in mind that whatever is created during implementation needs to maintained as the organization changes and grows. So the cost of maintenance should be as low as possible. Delta link capabilities should be least used.

Some portal roles need to be assigned to huge number of people in the organization whose responsibilities are heterogenous in nature. Roles should be designed only if they are usable. For the people in the company who are not versed with the IT solutions, designing role is waste of time and money and maintaining it is a paranoid.

SAP Blogs

Pages