In my recent blog HCM Processes & Forms: Images/Logos and Reusable Components for FPM forms, I touched on the fact that more advanced things could be done with FPM forms using composite UIBBs, but I left it pretty much at that point and to your own mind to come up with examples. Well, in this blog, I want dive deeper into this topic. I will not give away all of my secrets, but I will show off a little. (haha) Just kidding.
Seriously, I put together this blog in hopes that people will really "get it" and embrace the idea that with the "new" evolution of HCM P&F via HR Renewal, our FPM-framework based forms can be so much more than just a "form". We can now create fairly complex applications WITHIN the HCM P&F and FPM frameworks themselves!!!
How it all began....
Again, as I showed in my blog HCM Processes & Forms: Images/Logos and Reusable Components for FPM forms, you can create a "composite configuration" and display multiple UIBBs on a form. In the example I showed, I displayed a company logo along with the process information coming from your HCM P&F configuration in the "header" of your form. However, our "non-HCM P&F component" was just a static image. There was not a whole lot going on there, but I alluded to the notion that much more could be done. So what was I talking about? What if......what if our HCM P&F UIBB could "talk" to our non-HCM P&F component? What if we could exchange data? Hmmmmm.....that would be kinda neat eh? An immediate example came to mind for me.
What if we had some form that showed an employee's address from our HCM P&F configuration but then we displayed a non-HCM P&F component on the same form that displays a Google Map that showed that address location? It would be pretty cool eh? What if we made our "Google Map component" simple and generic enough that we could use it any where to show an address? That would be cooler! So I set off to build this.
My search began first looking at what the HCM P&F framework might expose to us (such as a class or interface). I was hoping I could simply write some code that would get a "handle" on the instance of one of our HCM P&F classes that would provide me all the form fields and values. I searched and searched. But as I was searching, digging deep into code, following down this idea and that, it hit me that if I went that path, I would be building something TOO tightly coupled and dependent on the HCM P&F framework. Remember....I wanted to create a simple, generic "Google Map" component that I could use in HCM P&F and elsewhere if needed (Reusability for the win! haha).
So then, I looked at how the FPM framework allows us to create "interaction" between our UIBB components. For UIBB-to-UIBB communication, SAP provides a number of options. kunath.uwe covered this BRILLIANTLY in his simple, concise blog Data exchange possibilities in Floorplan Manager(I advise you to read and absorb this!) Also, from the mouth of the King of ABAP himself, thomas.jung, he states in a 2010 forum thread http://scn.sap.com/thread/1832040 (prior to the "wiring" option)...
 | "There are generally two different approaches to this. You can use a faceless shared data Web Dynpro Component. This is special interface for the WD Component that is part of the FPM framework. You then use cross component context binding to share a single context between all inner UIBB Components. The other approach is simply to share data via a normal ABAP class. Generally you use a singleton pattern so that all UIBBs share a single instance of the class. This approach has lower memory requirements because the cross component context binding approach needs to copy the data of the share context into each UIBB. This approach is also easier to use when you have Generic UIBBs which are implemented as feeder classes instead of Web Dynpro Components. The last 15 minutes of the TechEd session CD203 - Best Practices for Web Dynpro ABAP was dedicated to this very topic." |
In the same thread, fellow SAP Mentor, chris.paine mentions...
 | "I've actually combined these two approaches to data sharing - I've passed a class reference in the shared data component. This is nice (in my opinion) because it is very obvious where the data is coming from and who it is shared with. It also means that there is not a huge overhead in passing data through the shared context, because you are just replicating a reference to a class instance. And - you don't have to deal with singleton classes :-). So if you want/need to extend your implementation at a later date (for example embedding multiple instances of the same "app" in the one window - or suspending and resuming to another instance of the same app :wink: you can then do this. (NB - suspend resume to launch another FPM app does not work because of this (amongst other things)). NB a shared data component need not be faceless! I certainly have "shared data" UIBBs that also have UI components - possibly not best practice - but it certainly can be done." |
| I decided to go the Singleton route for a number of reasons. First off, it is EASY! (haha) Second, I could have gone the "fancy" route and use FPM "wires", but I thought it would be really cool to show an interaction between our HCM P&F configuration using a Generic Service (backend) and our Google map WDA component view (frontend). Now of course this probably flies in the face of "separation of concerns" but oh well....I am a bit of a rebel (haha). |  |
Making magic happen...
First off, I built a very basic Singleton class (there are PLENTY of links/sources/tutorials you can find with a simple web search on "what" makes an ABAP class a Singleton and "how" to create one). My class had the typical "GET_INSTANCE" static method (which controls the fact that only ONE instance of our class can exist...ie. SINGLE-ton), and a handful of "public" attributes I would need for an address (street, city, state and zip). I could make this more OO strict and make "private" versions of each attribute and create SET/GET methods for each, but that is more work than is needed for now.
Second, I created my "Google Mappers" WDA component. Make sure you make it a FPM UIBB component by implementing the correct interface!
The rest is very simple. There are MANY links and examples around the web for how to integrate Google Maps with WDA in all manner of ways, however, I took a few ideas from this very basic example by Fareez Ahamed in his blog http://webdynpro4abap.blogspot.com/2012/12/google-maps-in-web-dynpro-abap.html (again, to keep this easy and develop quickly as a proof of concept...his example does not work exactly as what I built but it did give me ideas). I have a "view" with just an "image" element on it (static Google Maps use a "<img>" tag to create the map image...do NOT use an iFrame).
The context for my WDA is very simply 3 attribute values:
- LOC :this is our "location"/point of interest
URL: this will be our constructed URL and is what we bind as the "source" for our image element in our view
ZOOM: this allows us to set a value for the "zoom" on the map that we pass as a URL parameter (default value = 15)
In the method PROCESS_BEFORE_OUTPUT of our component controller for our "Google Mapper" WDA, we call our own private method SET_MAP_DATA that handles "talking" to our Singleton instance to pull (GET) the address information and set our context values. You might think that this would be better handled in the method WDDOINITof our component controller, however, you will find in debugging that that method gets called before our HCM P&F Generic Service INITIALIZE method can set the address values. You really have to keep in mind the WDA Phase Model calls.
WARNING: I only put in the images of code. This keeps people from simply cut-n-paste coding instead of doing a little work and understanding what is going on.
The real "magic" happens in our view's WDDOINIT method where we set the URL "source" for our image to use (per binding to our context). The parameters we pass as we construct this URL are very important. I read the Google documentation to figure this all out (https://developers.google.com/maps/documentation/staticmaps/ ).
So this is a pretty simple WDA component now. The VERY nice thing now is that this generic "Google Mapper" component can be used with ANY other component as long as the interact with our Singleton class (could change this later). So not only for HR and things like employee's addresses, but also warehouse locations, customer locations, etc. where a simple address is used. (WOW! haha).
Finally, we created a Generic Service called Z_GOOGLE_MAPPER in our form scenario configuration for our process.
It is a very basic service with one operation that we have mapped our address related fields to call.
Because we just want to show the employee's "current" permanent address when the form first is displayed, we can handle this in our INITIALIZE method (for now, our SET_MAPPER operation is just empty and used to get our fields to our Generic Service (old HCM P&F trick haha).
Our INITIALIZE method calls a private method SET_MAPPER_VALUES. I made this a separate private method because I might want to use it later so it is now reusable (*hint hint*).
So in summary, we have a HCM P&F Generic Service that will first create the instance of our Singleton class and then set it's address attributes. Then we have our "Google Mapper" WDA component that will get reference to and read the Singleton class address attributes and set it's own context. Because we have bound one of the context values to our view's "image" element, it will then display our static Google Map showing a "pin" on the employee's address. Don't believe me? Here is the process when we execute it...
So yeh....there it is....Pretty cool eh? But let's step it up another notch! (haha)
Taking it to another other level...
I will not give away all the details (the "how" and "where" and "what" I did), but let's just say that I....
- extended the Singleton class to handle both single locations and distance between points
- fleshed out the "Do Operations" method in my Generic Service to handle our "new" address
- added zoom functionality to my "Google Mapper" component
- added handling of distance/pathing between two map points to the "Google Mapper" component when constructing the URL
So now if I execute my "Relocation" process, it first shows the employee's current address as before...
You can also see how I can control the "Map" component independent of the HCM P&F FPM framework when I use the "zoom controls" buttons (here I clicked twice to zoom in).
Now the employee's "new" address is entered and the user clicks "Check"....
We can now see the path/distance between the "old" and "new" address (this is just a "path" and not driving directions...which can be done...but requires using other APIs and services which is more work than this example really needs for "proof of concept"). Just for grins, I also show here that I bound my zoom buttons to a context attribute so that I can hide them when the maps is showing distance between 2 points (they show when only the first address is shown). Ok...ok....too much showing off eh? haha
Now THAT is REALLY cool eh?!?!?! haha This should REALLY get your gears spinning and thinking about all the many more possibilities out there. As I said, whereas we use to think of HCM P&F as an easy "form" handling framework, we can think of it in a whole new way....as a rapid application development tool.
I must say....this was VERY fun to build! As always, I really hope this helps others. More blogs coming as long as folks keep enjoying them (or if I win the lottery haha). Till next time...
- SAP Managed Tags:
12 Comments
