Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
ChrisSolomon
Active Contributor
0 Kudos

            What better way to start a blog than with a "cheesy" 80's song? (I can hear it now..."Gee thanks, Chris, for putting that song in my head now.") But it fits right in with this "cheesy" little problem that often stumps HCM Processes and Forms developers.....the never ending spinning wheel! I see this question come up time and again in the Adobe forms forum, so rather than continuously cutting-and-pasting or linking past replies in, I figured it would be easier just to put together a little blog about it.

The symptom: The user pulls up the initial Adobe Interactive form view for their process from HCM Process and Forms in the "Start Application". They do whatever they need to do and click the "Check and Send" button to proceed. The small pop-up window appears with "wait" and a graphic that spins.....and spins.....and spins......and spins......and you guessed it.....spins. On and on and on, it will not stop spinning. It does nothing else. It does not continue. You do not pass "go" and collect your $200 (sorry, had to throw in the Monopoly board game reference). It is here after known as the “infinite-spinning-Wait-wheel”.

 

 

 

 

 

 

 

So, “what to do now?” is the question. This is most often due to 3 possible iues listed in the order of most common occurrence:

1. The Javascript library needed for ZCI has not been included/attached/embedded in the form. 

This is the MOST often overlooked step when developing an Adobe Interactive form for HCM P&F from scratch. More times than I care to admit, I have launched a process, saw the spinning wheel spin off into infinity and thought “awwwww crap!!! I forgot to include that dang Javascript library!” Hey, it happens to all of us. You get so focused on building your form, making it look all pretty and function correctly, and you totally overlook this one little simple step.

From the top menu, you need to select “Utilities” and then select “Insert Web Dynpro Script” from the drop down menu. 

Now, if you look at the hierarchy of your form’s layout, you will find at the very bottom that you have attached the ContainerFoundation_JS.

And that’s that. Just that easy! ...and even easier to forget. (haha)

 

2.  The latest version of the ISR Controls library has not been used.

SAP’s backend communicates with the Adobe forms via the ISR framework. Previous versions of the ISR form controls library (controls like textboxes, radio buttons, drop downs, date pickers, etc) were built with the “old” Active X version of the forms in mind. However, the newer ISR controls library are built based on the ZCI (Zero Client Install) version. Therefore, they contain Javascript on their events that are needed to function correctly. These libraries are installed and must be maintained on your local machine for forms development. Therefore, if you have installed an older version and have not updated it, you will be using “bad code”. Please refer to SAP notes 947633 (Current ISR Controls Libraries) and 741381 (ISR: Documentation for ISR Control library) on the Service Marketplace.

3. The user is running an incompatible Adobe Reader version.

This one is pretty straightforward. Basically, Adobe Interactive forms require that you are on at least a minimum version of the Adobe Reader. Personally, I keep my Reader version up-to-date. As of right now, I know of no issues with the 9.1 version. Prior to that, I ran 8.1.4 just fine. Just check your version and update accordingly.

EDIT: 4. LiveCylce Designer version (08/04/09)

Another interesting one....one of our developers kept building processes/form and every one of them would "spin" on "Check and Send". All of our forms worked fine. He joked that he was the "King Midas in Reverse" for forms development. In debugging, we could see the calls go into the ISR class for initialization, but after that, control never passed back from the form to the ISR framework. After much frustration from all of us in looking over every little detail, we checked one more thing....LiveCycle Designer versions....ours was 8.01.3250....his was 8.01.2088. Was that it? Could it be that simple? I recreated one of his forms from scratch and viola....it worked! Was it that simple? Could it just be a version issue? I took one of his other forms and rather than recreate it, I regenerated it. It didn't work. There was something else. But what? Well, just for grins and giggles, I removed/deleted the "foundation JS" script from the form, saved, regenerated, added the script back from my machine, saved and generated. It worked!!! What?!?!?! I have feeling that the different LiveCycle version "somehow" embedded the script in some different way than our versions. In any event...it was NO fun to hunt down and figure out. Our "King Midas" updated his version, and now he his happily developing forms once more. NOTE: as posted in the comment below, newer ADS version handles embedding the script for you...no need to add to your form.

 

 

That covers the three  four most obvious and often overlooked reasons behind the “infinite-spinning-Wait-wheel”. Past these, if the symptom still occurs, it’s time to get your BASIS/NetWeaver Engineers involved. For instance, the only other time I have seen this happen and it has not been related to the above reasons is when we were attempting to access the process/form via the internet through a firewall (this becomes all tangled up in proxies and hardware devices). At this point, you know the golden rule as a developer right? If all else fails, blame BASIS! hahahaha

5 Comments
Labels in this area