AL-Infotech

It took 3 months, but finally here is the last blog about the major features that were added to SAP NetWeaver Portal 2004, SP15. 

Today we look at the changes to the XML Content and Actions tool, which lets you automate the creation of portal content. Instead of using the administration interfaces to create iViews, pages, worksets, roles and other portal objects, you can simply upload an XML file with all the information and — poof! — all you content is created.

The tool is good if you are designing content on a test machine, and then you want to create the content on another machine. Also, if you need to create a lot of objects that are similar — several roles with similar structure; you create the XML for one role, and simply duplicate it in the file and upload the file.

In addition, some companies design their content based on some back-end data, or use some tool (such as Excel) to define the content. From Excel, for example, you can then create a small conversion algorithm to export the Excel data to XML, and then upload the XML.

The tool is a lot like the PCD Inspector, in that it provides a type of backdoor for modifying PCD content. And like the PCD Inspector, you must be careful and check your XML, as you can create a lot of content — but also do a lot of other things, perhaps unintentionally, to harm the portal.

A Quick Review

Open the tool by going to System Administration –> Transport –> XML Content and Actions.

The import tool lets you upload a well-formed and valid XML file. After you export the file, the portal parses it and creates the portal objects and performs the actions defined in the XML. A report of the execution is displayed, showing what objects were created, what actions were performed, what sections did not parse correctly, and so forth.

How to Write XML to Create Content

The XML for the XML Content and Actions tool is, essentially, a collection of tags, possibly nested, and each tag defines an object to create, modify or delete. The type of object is specified by the handler name provided in the objectClass attribute.

For example, to create an iView, you specify com.sapportals.portal.iview.

You can also add tags, that specify an action — such as deleting all objects from a folder, running another script, or assigning users to groups. These tags are not nested.

The following is an example file that creates a folder, a workset in the folder, a page in the workset, and an iView in the page:


   
   

   
   

      
      

         
            
               
            
         

         
          template=”portal_content/com.sap.pct/admin.templates/pages/${namespace}.portalpagetemplate”
objectClass=”com.sapportals.portal.page” create_as=”1″
title=”User Data Import Page”>

            
            

               
                  
                     
                  
               
            
         
      
   

What’s New

The main addition in SP15 was the addition of an export tool, that lets you take existing content and create an XML file based on it. You can then take this XML file, modify as needed, and upload the file so that the content — or similar content — is created on the same portal, perhaps in a different area, or on another portal.

With the tool, you do not need to code XML by hand. You can design the skeleton of what you want and export it to XML. You can then modify the attributes, copy the elements to create additional objects, and so forth.

In addition, a large group of handlers were added in SP13, with which you still may not be familiar. The following objects can now be created:

• Translation worklists
• Related items (of iViews)
• System aliases

The following actions can now be performed:

• Run a script from within another script
• Copy and mirror content
• Assign users to groups and roles

Documentation

And, of course, we have a document that explains all the rules for building a valid XML file for the XML Content and Actions tool. It also lists all the objects you can create and all the actions that you can perform.

The documentation is located at How to Automate Content Creation via XML.

You’re a BPX, it’s Monday morning and you’ve arrived at a brand new client. You have a limited engagement of one week. Your mission: to produce documented recommendations for new technology supporting an existing business process requiring some redesign. How do you get the job done?

This scenario is a common occurrence to the Business Process Expert who functions as the ‘hired gun’. It is not uncommon for the BPX to be called into situations which require high- to mid-level analysis and a quick, but comprehensive set of recommendations as output.

To accomplish this task, the BPX must deal with the following factors:

- quickly developing a relationship with the client, to establish trust and credibility
- sorting through the business issues, often with little or no understanding of the client’s business or particular circumstances
- analyzing the technology in place and understanding the future of the landscape (i.e., upgrades, etc.)
- designing (at a high-level) various alternate solutions
- creating thorough recommendations (and the corresponding document).
How does a BPX quickly establish a relationship with a new client?
To establish trust and credibility, it is important for the BPX to become a ‘trusted advisor’ to the client as quickly as possible. Sometimes the client is aware of the BPX’s profile and history; however, regardless of the client’s prior knowledge, it is still imperative that a face-to-face relationship be established to increase the productivity of interaction between the client and BPX.

Clear communication is key between a BPX and any client, but particularly essential in a short-term assignment which results in ultimately influencing business change. Some of the tactics of a BPX for creating a relationship should include:

- listening attentively to the client (often they drop hints about the pains in their culture; sometimes they may actually be explicit)
- active listening: asking questions for clarity
- demonstrating forthrightness: be clear that you do not have a hidden agenda, and that you are working for them
- briefly outlining your own experience in two minutes or less, focusing on other occasions where you were a trusted advisor

Typically, this openness will precipitate a comfortable, receptive relationship which facilitates your getting the information you need to create your conclusions.
How can a BPX sort through business issues when he/she knows nothing of the client’s business?

This can be a tricky situation and often requires reliance on two things: your past experience and intuition. However, that’s sometimes easier said than done.

It is easy to feel like a fish out of water in a foreign environment, however one of the surest ways to gaining an understanding of the client’s business environment and issues is by listening for similarities to your own past experiences. Often situations, although radically different in exterior application, can be very similar in nature at their core.

By actively listening to the client and asking clarifying questions regarding business priorities and areas of greatest pain, a BPX can quickly get a sense of where the most urgent concerns exist. Generally, this will naturally become evidence to formulating recommendations.

It is critical to accumulate information that forms the “bigger picture” which includes the client’s culture, technical environment and political landscape. Having this bigger picture can direct the recommendations to solve very specific issues.
Analyzing the technical environment

While seemingly straightforward, it is often necessary to dig deep into the system landscape only to ensure that nonconforming systems are indeed identified in any formal architecture discussions. No one likes surprises at the end of an assignment where he/she discovers that there was a complete application built for one area of the business outside of the main landscape, which executed the exact requirements of the consulting assignment! Know all the players involved, even if you must unearth clues through your listening.

Also, ensure that a complete technical landscape is provided to you, inclusive of the go-forward plan for technical upgrades. This can impact the timing of implementation of your recommendations or can drive to a phased implementation approach.
Now that I have the information I need, how do I design the solutions?

This step typically involves your own personal style. Generally speaking, the recommended solutions will begin to become apparent throughout your discussions with the client. As the client unfolds their circumstance and explains their issues, the possible solutions often naturally ‘fall out’ of the analysis.

Again, the development of solutions is reliant on your own knowledge and experience, and in cases where some information may not be available, a healthy dose of your own intuition may be required. More often than not, implementation of similar solutions follows a similar path at its most fundamental level. Intuition, then, can be useful in making a best guess on high-level timing of a project or an approach to phasing-in a solution.
And, finally, I have to write the recommendations document: what should I address?

Typically, a comprehensive document should include the following sections:

- Introduction (why is this document being created) - Scoping Summary (when the exercise and occurred and what the general outcome was)
- Detailed Business Process Information of the specific scope reviewed
- Alternative Recommendations (a text description of the recommended solutions)
- Organizational Impact Assessment (how will the organization be affected)
- Interfaces (a brief description of any foreseen technical interfaces into the new solution)
- Security, Authorizations and Roles (how the new solution will impact who does what in the organization, both from a business and a technical point of view)
- Integration Points (what other parts of the business and technical landscape may be affected by the new solution)
- Training Requirements (at a high-level)
- Description of Improvements and Business Benefits (a brief summary)
- Resource Estimates of the main actions to be taken to implement the solution
- Proposed Timing of the Activities
- Issues (any issues within the organization which have been identified and must be addressed as part of the project)
- Key Success Factors (what will it take to make the project successful)
- Project Assumptions (what was assumed to create the recommendations and resource estimates)

Closing thoughts…
The expectation of the client is that the BPX has the knowledge, expertise, ability and confidence to ‘hit the ground running.’ This can be a tall order in politically difficult situations, however by sticking to the basics of analysis and design as discussed above, the BPX has excellent odds of being successful under most circumstances. These tactics have worked for me and for others. Honing one’s skills through repeated exercise is the key for owning the process of quick situation analysis.