After you read the title of this blog, you are probably thinking to yourself: “So what. This is a simple matter of integrating the iViews or Pages that originate from the Business Package via a Guided Procedures (GP) ‘Page / Portal IView Callable Object’”. If this was all that this blog contained, then you would be correct. However, if you look at content from older Business Packages (BP), especially those originating from the old EP 5.0 environment, you will see that many work with portal eventing. The usual workflow in this older BP setting is that the user searches for a particular item – using a “My Favorites” or search IView – and then all other visible BP iViews update automatically to show related content. In a process setting, however, users shouldn’t have to search for items if the information is already available – for example in the process context of a GP process.
Motivation
Now, you might be wondering: “Why do I need to know this?” Well, as I have described in Enterprise SOA Explorations: Fragments, the transition to a purely SOA-based world won’t happen overnight. Thus, there will be a period when Enterprise SOA and legacy applications must co-exist – a hybrid architecture. This blog describes one particular manifestation of the architecture in that iViews from Business Packages can be seen as legacy applications (in this case, referring to applications that are not yet service-enabled). Inasmuch as one goal of a BPX is also to reduce the amount of development allocated for new processes, the re-use of these components (when they meet the process requirements) should also be promoted. One idea might be to create a new UI using Visual Composer with the same functionality but one should never underestimate the amount of business logic that is included in these older BP iViews.
Technical Environment
A Caveat: Our solution isn’t perfect. There are still some caching problems that sometimes occur but the general solution is working; thus, it is relevant for the BPX community.
A Note: A boring integration based on the Portal Content Directory (PCD) item would have been an appropriate example but I wanted to pep things up a bit by using GP’s ability to pass process context parameters to particular callable objects. This saves the user of having to search for a particular business object before getting the desired information. Furthermore, the user may not have enough information to find the correct item.
We used our 2004s SP 8 Test Portal plus the Business Package BPPRODUCT503 – in particular the page dealing with Materials.
Once again, we had similar problems regarding the passing of parameters to the Page or IView that I described in my Guided Procedures Explorations: Options for integrating remote Web Dynpro components. Thus, we had two choices regarding which Callable Objects to use – “Web Pages” or “Portal Page or iView”.
We ended up having to use the “Web Page” Callable Object, because we couldn’t pass the necessary input to the BP iView using the “Portal iView or Page” Callable Object. The problem was compounded in that we had to hard-code the URL of the desired page although the page was located on the same portal as the GP Runtime environment – not a very maintainable solution when transporting the process to other platforms.
We also had to directly access the page in the Portal Content Directory (PCD) instead of accessing it via a Portal Role. This configuration is not very satisfying and leads to additional work, because the necessary portal role must be taken into consideration in the GP environment instead of through the normal PCD and Use Management (UME) channels.
Thus, the URLused by “Web Page” Callable Object looked something like this:
Through the use of the parameter mapping inherent in the “Web Page” Callable Object, the necessary parameter was passed to the URL.
Although it would have been possible toinclude a single iView from the Business Package in our solution, we decided to use a page instead. This decision was made for two reasons: 1) a page would allow for the use of multiple iViews from the BP and 2) a page was technically necessary for our solution.
Technical solution
For the solution, we developed an invisible HTMLB iView (thanks to Mihaela Blum in Rumania for developing the iView and working out the cache problems) that propagates the parameter that originates from GP to the BP iViews using an EPCF event.
Steps involved:
1. In a process instance, an action is called that is implemented by a “Web Page” Callable Object.
2. A particular parameter is taken from the process context and passed to the Callable Object.
3. The Callable Object builds the URL and hangs the parameter from the process context onto the URL.
4. The portal page is called and the Propagator iView takes the parameter from the URL and transforms it to a EPCF portal event that is sent to the BP iViews.
5. The BP iViews respond to the event and show the information as desired.
In our example, we used the portal page with the BP iViews as an Info Callable Object for an action.
The first screenshot shows a process with our action.
The second screenshot shows the Info CO with the two BP iViews.
The user has the advantage that he/she doesn’t have search for the material to get the necessary information.
Technical Details
Originally, I had planned for some sort of generic iView that would work with all BPs that were portal-event-based. Unfortunately, implementation details prevented this goal from being accomplished.
The heart of the Propagator iView is the JavaScript code that takes the URL parameter and converts it into an event. The code snippet below shows the most important components.
function getURLParam(strParamName){ var strReturn = ""; var strHref = window.location.href; if ( strHref.indexOf("&") > -1 ){ var strQueryString = strHref.substr(strHref.indexOf("?")); var aQueryString = strQueryString.split("&"); for ( var iParam = 0; iParam < aQueryString.length; iParam++ ){ if ( aQueryString[iParam].indexOf(strParamName + "=") > -1 ){ var aParam = aQueryString[iParam].split("="); strReturn = aParam[1]; break; } } } return strReturn; } function generateEvent(){ EPCM.storeClientData( namespace, space_param, getURLParam(req_param)); EPCM.storeClientData(namespace,'AllKeys',space_param); EPCM.raiseEvent( namespace, event_name, '' ); } setTimeout("", 20000); window.onload = generateEvent;We have stored some values in iView Properties (for example, the namespace of the event to be sent) in order to have potential re-use of the iView. After the use of the iView properties, the generateEvent method would look like this:
EPCM.storeClientData('urn:com.sap.bor:BUS1001','objid', getURLParam(req_param)); EPCM.storeClientData('urn:com.sap.bor:BUS1001','AllKeys','objid'); EPCM.raiseEvent('urn:com.sap.bor:BUS1001','select','');There were/are a few problems associated with the solution. The majority of problems deal with caching and order problems while loading the iViews. If the Propagator iView loads too early and sends his event before the BP iViews are ready to receive the events, then these BP iViews don’t respond as desired by showing the information. Much depends on how fast the back-end can respond to the iView’s requests. This is the reason why we have used a timeout in our code.
The PropagatoriView is made invisible using the following iView Property settings:
- Show Tray = No
- Fixed Height (Pixels) = 0
- Height Type = FIXED
To see one example of the use of portal eventing in business packages, look at the SAP Help Pages for the Products BP.