Nakisa OrgChart 4.1 Portrait view Photo Disappear

Hi My Heroes,

In Ehp7.0 Nakisa 4.1 ; In Org.Chart's boxes' photos are disappeared, how can I make them appear?

If my memory fails me not; in Nakisa 3.0 we had a OSS note, is it same situation again??

Is it any bug or any other I dont know but this is a bit different situation from 4.0 SP1 and others.

Do you have any suggestion about that?

I've check /Nakisa/RFC_Report but I think I need miracle fingers and idea

SAP Managed Tags:
SAP ERP

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (0)

Answers (3)

Hello Everyone,

Having those X's removed from those 4 xml files mentioned above in .delta folder and then copying them into the below folder;

...\Root\.system\Admin_Config\<build>\AppResources\dataelementconfiguration

has made our changes effective and solved our problem.

Many thanks to all of you!

Regards.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Cong. Tunç

Have a Good Work..

Hi Mehmet and Tunc,

You may like to validate below items.

1. Create IP entry in etc/host file .

2. Content server virtual host Password works fine

Regards,

Dipak

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Dipak,

What I understand from your post is;

1) Create IP entry in etc/host file > Go to C:\Windows\System32\drivers\etc and add the relevant address to this file. Am I correct ?

2) Content server virtual host Password works fine > I am not sure if I got what you meant with that

Regards.

Hi Tuc,

Correct. Please add the IP address and domain name there. You can open host file in Notepad and update these details.

Regards,

Dipak

Hi,

I understand but what about the second thing you wrote "2. Content server virtual host Password works fine" ? Should I take any action about that ?

Regards.

Hi Tunc,

For Content server password just validate that it is not expired. Have you made changes to host file already ?

Dipak

Hi Dipak,

I have made the changes to the host file already but the result is unfortunately the same 😕

I am not sure how to validate whether the content server password is expired or not. Is there something certain that I should do for that ?

Regards

Hi Mehmet,

I haven't yet deployed 4.1 so haven't seen this myself. But have you read:

1959007 - Photographs are wrongly displayed in position hierarchies

However, this seems to be more about wrong photos, not missing ones.

Does the CDS log say anything of use?

Have you run an RFC trace to see what URI is being returned in the SAP RFC call?

Which views/details are affected?

Pos details panel?

OU Manager view?

Position Portrait view?

Stephen

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Stephen,

We store the photos in R3 system. On Nakisa, when I click on a position or an org unit which has a manager or an employee with a photo, I can see the photos on the right panel of the detail (org unit, position, employee etc.) screen. However, I can not see the photos "in the boxes" which should have been deployed on the left side of the box. Instead, it shows just nothing but a blank photo. Starting from this point, I don't think it is about wrong photos because I see the photo correctly in the pos details or org unit details panel (for managers). My problem is with the boxes.

In addition to that, I have checked the error log and it does not say something particular but I will send it here anyways.

I neither see manager photos nor employee photos so I should say ou_manager (with portrait) does not work as well as pos_portrait view in my case.

I have checked the SAP Note you recommended but before going deep into that, I want to be sure if my case is about what you recommended because as I mentioned above, my problem is not about "wrong" photos. I will be grateful if you can assist me about this.

I checked almost all the relevant forums related to this photo issue and have read all the topics. I have seen some other people also faced this issue as I am doing right now but most of the suggestions and Notes in those topics are related to Nakisa v3.0. However, I should say we upgraded the Flash Version to 11.7 in case of any incompatibility.

Kind regards.

Meanwhile Log File's content is below..

17 Apr 2014 02:21:50 INFO com.nakisa.Logger - changeview on OrgChartAppEventProcessor took: 248ms

17 Apr 2014 02:21:53 INFO com.nakisa.Logger - ...Request is not required to be verified. For action: chartviewdetails. For processor OrgChartAppEventProcessor

17 Apr 2014 02:21:53 INFO com.nakisa.Logger - Invoking action:chartviewdetails [4616a8a87aa0467a9c6507c4192dffa2]. For processor OrgChartAppEventProcessor. Against controller OrgChartCtr

17 Apr 2014 02:21:53 INFO com.nakisa.Logger - ...Request is not required to be verified. For action: updateNotifications. For processor NotificationsProcessor

17 Apr 2014 02:21:53 INFO com.nakisa.Logger - Invoking action:updateNotifications []. For processor NotificationsProcessor. Against controller NotificationsCtr

17 Apr 2014 02:21:53 INFO com.nakisa.Logger - updateNotifications on NotificationsProcessor took: 1ms

17 Apr 2014 02:21:54 INFO com.nakisa.Logger - FunctionRunner.executeFunctionDirect: /NAKISA/OC_POSITION_DETAIL took: 1154ms

17 Apr 2014 02:21:54 INFO com.nakisa.Logger - chartviewdetails on OrgChartAppEventProcessor took: 1487ms

17 Apr 2014 02:21:54 INFO com.nakisa.Logger - com.nakisa.framework.utility.PostRequestActionRegister.callAction(PostRequestAction) : Calling: PostRequestAction [class=com.nakisa.framework.data.commandProcessor.impl.sap.FunctionRunner, method=releaseAllClients]

17 Apr 2014 02:21:57 INFO com.nakisa.Logger - ...Request is not required to be verified. For action: chartviewdetails. For processor OrgChartAppEventProcessor

17 Apr 2014 02:21:57 INFO com.nakisa.Logger - Invoking action:chartviewdetails [4616a8a87aa0467a9c6507c4192dffa2]. For processor OrgChartAppEventProcessor. Against controller OrgChartCtr

17 Apr 2014 02:21:57 INFO com.nakisa.Logger - ...Request is not required to be verified. For action: updateNotifications. For processor NotificationsProcessor

17 Apr 2014 02:21:57 INFO com.nakisa.Logger - Invoking action:updateNotifications []. For processor NotificationsProcessor. Against controller NotificationsCtr

17 Apr 2014 02:21:57 INFO com.nakisa.Logger - updateNotifications on NotificationsProcessor took: 2ms

17 Apr 2014 02:21:57 INFO com.nakisa.Logger - FunctionRunner.executeFunctionDirect: /NAKISA/OC_POSITION_DETAIL took: 100ms

17 Apr 2014 02:21:58 INFO com.nakisa.Logger - chartviewdetails on OrgChartAppEventProcessor took: 305ms

17 Apr 2014 02:21:58 INFO com.nakisa.Logger - com.nakisa.framework.utility.PostRequestActionRegister.callAction(PostRequestAction) : Calling: PostRequestAction [class=com.nakisa.framework.data.commandProcessor.impl.sap.FunctionRunner, method=releaseAllClients]

17 Apr 2014 02:22:03 INFO com.nakisa.Logger - ...Request is not required to be verified. For action: changeview. For processor OrgChartAppEventProcessor

17 Apr 2014 02:22:03 INFO com.nakisa.Logger - Invoking action:changeview [pos_portrait_dynamic, OrgUnitTypePositionHierarchy]. For processor OrgChartAppEventProcessor. Against controller OrgChartCtr

17 Apr 2014 02:22:03 INFO com.nakisa.Logger - ...Request is not required to be verified. For action: updateNotifications. For processor NotificationsProcessor

17 Apr 2014 02:22:03 INFO com.nakisa.Logger - Invoking action:updateNotifications []. For processor NotificationsProcessor. Against controller NotificationsCtr

17 Apr 2014 02:22:03 INFO com.nakisa.Logger - updateNotifications on NotificationsProcessor took: 1ms

17 Apr 2014 02:22:04 INFO com.nakisa.Logger - changeview on OrgChartAppEventProcessor took: 250ms

17 Apr 2014 02:22:07 INFO com.nakisa.Logger - ...Request is not required to be verified. For action: changeview. For processor OrgChartAppEventProcessor

17 Apr 2014 02:22:07 INFO com.nakisa.Logger - Invoking action:changeview [pos_portre, OrgUnitTypePositionHierarchy]. For processor OrgChartAppEventProcessor. Against controller OrgChartCtr

17 Apr 2014 02:22:08 INFO com.nakisa.Logger - ...Request is not required to be verified. For action: updateNotifications. For processor NotificationsProcessor

17 Apr 2014 02:22:08 INFO com.nakisa.Logger - Invoking action:updateNotifications []. For processor NotificationsProcessor. Against controller NotificationsCtr

17 Apr 2014 02:22:08 INFO com.nakisa.Logger - updateNotifications on NotificationsProcessor took: 2ms

17 Apr 2014 02:22:08 INFO com.nakisa.Logger - changeview on OrgChartAppEventProcessor took: 250ms

17 Apr 2014 02:22:19 INFO com.nakisa.Logger - [Admin console] admin user 'admin' successfully logged in

17 Apr 2014 02:23:10 INFO com.nakisa.Logger - ManagerInit: Time took to setup Build: 9543 ms

17 Apr 2014 02:23:12 INFO com.nakisa.Logger - ManagerInit: Time took to load settingsResources: 382 ms

17 Apr 2014 02:23:16 INFO com.nakisa.Logger - ManagerInit: Time took to load appResources: 1515 ms

17 Apr 2014 02:23:17 INFO com.nakisa.Logger - ManagerInit: Time took to load extractorSchema: 86 ms

17 Apr 2014 02:23:17 INFO com.nakisa.Logger - ManagerInit: Time took to load OTFSchema: 460 ms

17 Apr 2014 02:23:17 INFO com.nakisa.Logger - ManagerInit: Time took to load Role Mapping: 12 ms

17 Apr 2014 02:23:17 INFO com.nakisa.Logger - ManagerInit: Time took to load Roles: 2 ms

Mehmet.

Switch from standard (flash) to basic (HTML) mode in settings. What do the views show?

Are they standard "silhouette" portrait images, are the images displayed correctly or are they "broken image" place holders?

This will either give you some insight into an underlying issue or identify the issue as affecting standard (flash) mode only. It may also be that being able to directly review the image source URL in the page HTML could help you identify any potential errors in the URL generation.

Regards,

Stephen.

Hi Stephen,

If you mean “Organization Structure -> Position Hierarchy -> Views -> Pos_Portrait” by Settings, I have two options which are;

a) Flash
b) Flash and Html

Default choice is b. I changed it to “a” and checked what the outcome is. The result hasn’t changed. All I see is standart silhouette portrait images. What you meant by standart silhoutte portrait images is a white background with a grey head image placed on it I guess J That’s what I see.

If you mean something else by Settings, please let me know and I’ll check it.

Kind regards.

In the end user interface (rather than AdminConsole) there is a user settings option - cog icon, top right. You should be able to switch between the two modes in there for a single user without restricting the mode on a hierarchy for all users.

Hi Stephen,

We have tried what is suggested but we still receive a standart silhoutte portrait image as below in both ou_manager (with portrait) and pos_portrait views.

Kind regards.

Tunç also is working for that;

Is there any reset build and publish method will use?

Or any authorization problem can be possible?

What is your suggestion?

If you are split in it working between views and details panels then it can't be an auths issue.

My next step would be to debug the RFC in AdminConsole as per Stephen's earlier suggestion. Details are in the Admin guide for how to do this. From there you should be able to identify the issue as being in the RFC or in the config. This would then dictate a way forward.

Your alternative is to submit an issue by OSS. For that I would first create an out of the box build (just based on a standard build with minimal config set to allow visualisation) and check that the issue occurs in that to remove any possibility of it being purely related to your particular configuration.

Hi Everyone,

I have debugged the RFC Trace and something about URL cought my eye. The URL is far too long and I know it should not be more than 256 characters if I am not mistaken ? As I mentioned above, we are storing the photos on R3 system and while generating the URL the character amount becomes enormous.

What could be the possible solution ? I think we have found something useful in this issue.

Regards.

Tunc.

MSIE is supposed to be able to cope with URLs that are 2,048 characters long so if there is a restriction it would seem to be in the application and affecting both in Flex and HTML.

What happens if you enter the image URL directly into the browser address bar. Does the correct image get rendered then or do you get an error message?

Regards,

Stephen.

When we enter the image URL directly into the browser address bar, the image displays correctly as it displays correctly in the details panel and we do not get any error message.

While we are debugging, we tried to change the URL and make it a shorter one but at that moment, the program did not allow unless we give a URL less than 256 characters. That's why I thought the restriction is up to 256.

Okay - so it is on the function module side.

I guess logically speaking there are two options:

Modify the function module to increase the length of the URL it is able to return to OrgChart.
Reduce the length of the URL being passed.

I know HRWPC_RFC_EP_READ_PHOTO_URI is used to get the portrait URL ... so presumably it would be this that would need modifying to increase the length. I'm not an ABAPer so I'm not sure what implications this might have elsewhere. If there was concern then I guess it could be duplicated but then it would need to be aligned for any future updates.

In terms of shortening the URL, I guess if you could define something shorter in a DNS entry on your network and then amend the web dispatcher URL to match (see URL generation of Change Own Data Photo | SCN) then this could shorten the URL a bit ... but I guess it depends how much in excess of 256 characters you are as to how practical this approach might be.

Regards,

Stephen.

I will look through the options and the link you have posted but at the same time, I would like to ask a question. I am reading all the problems and related OSS notes about this issue in the community and I have seen something called crossdomain.xml file. Is this file a must ? To be honest, I don't know what that file stands for but almost all the notes about this photo issue recommends that file to be put under SAP Web Application Server. Do you think my problem can also be related to this ?

Regards.

Cross Domain XML definition.

The file is used to specify that something can accept data from multiple domains (e.g. accessing foo.com and bar.net data from foo.com).

From what you described earlier it sounds like the data is getting through and when you put it in the browser, access is not an issue.

I don't see anything in the CD-XML specifications that would allow you to redefine the URL length.

Regards,

Stephen.

I understand. So the issue seems more complicated than I thought I have one more question: "if you could define something shorter in a DNS entry on your network and then amend the web dispatcher URL to match" > for that, is it something I can do by myself or do I need Basis assistance ? I am normally a HR consultant and this stuff does not ring the bell too much to me 😕

Regards.

So this would definitely be something to speak to basis about and they will probably discuss options with whoever manages the networks and DNS. However this is just an idea of how you might be able to shorten the URL based on there being two fundamental options of how to address the issue. The guys who know the internals of your infrastructure might well be able to offer up some alternatives (i.e. better options) for shortening the URL or advise on the practicalities of extending the number of characters that can be returned in the URL.

The web dispatcher URL modification might be useful if you had a URL like ...

http://myserverhasareallylongname.mydomainisnotveryshorteither.com/{rest of path}/12345678.jpg

... you might then be able to add a DNS entry (e.g. "portraits" redirects to the server above) and reconfigure the dispatcher to reduce the URL to (for example)...

http://portraits/{rest of path}/12345678.jpg

... but if {rest of path} would still exceed your 256 character limit this wouldn't get you any further.

Even though I'm probably quite technical, I've never done any basis admin or ABAP (though I have done a little network management in a past role) so I can't speak with any great authority on how to carry out the options above. Just generalities and theoreticals. So you really shouldn't feel bad if this is not ringing any bells for you!

Tunc.

I just saw your post on another thread relating to this and it prompted me to go back and re-read some of the earlier entries in this thread as well as through some other threads that post linked to.

Mehmet states:


I can see the photos on the right panel of the detail (org unit, position, employee etc.) screen. However, I can not see the photos "in the boxes" which should have been deployed on the left side of the box. Instead, it shows just nothing but a blank photo.

According to the OrgChart feature checklist, both the views and the details panels use HRWPC_RFC_EP_READ_PHOTO_URI to return the URL of the photo. So now I'm a bit confused as to why the function module can return the URL to one place in OrgChart but not the other. It doesn't make sense that this is a URL length issue in the function module otherwise it would never work - i.e. it would not work for views or details panels.

In the other thread it doesn't actually say if it is loading the default photo or no photo at all in the views, but it sounds like it might be similar to this issue where there really was no image at all being displayed in the views (and was local network configuration related). Since you get the same behaviour between HTML and Flash/Flex modes, it shouldn't be resolved by the crossdomain.xml. It could be that the default behaviour has changed between versions - i.e. default image displayed in the latest versions rather than no image (in the older versions); so perhaps the double encoding restriction on the reverse proxy could be the cause. That could be something to investigate with your basis and network folk.

Regards,

Stephen.

Hi Stephen,

I have talked to the basis and network team here but unfortunately they said they do not get what "double encoding restriction on the reverse proxy" is about 😕 I have read the long reply of yours about encoding/decoding and made also the basis team read it but as I said, they couldn't get what it is.. I know your message is quite explanatory in every aspect but may I ask is there another way to tell this issue, maybe more simpler ?

I would very appreciate that.

Regards.

Hi Tunc.

I'll do my best....

A proxy server is an intermediate server that carries out some sort of fetching/sending of data on behalf of another computer. So if you have a computer A (e.g. client PC) contacting a computer B (e.g. web server), but you are using a proxy server P, the traffic would go from A to B and B to A via P. P is in effect working on behalf of A.

A forward proxy is one centred around the end user computers whereas a reverse proxy is centred around servers. For more info, check out...

When you have a URL for a resource it is formed of ASCII characters in accordance with a URI scheme and some localised rules. If you want to know more check out section 2 of RFC3986, but basically sometimes the characters in the string are encoded using "percent encoding". A common example of this is a space (" ") which is encoded to "%20". So whenever you see a "%20" in a URL, this is equivalent to " ". The percent symbol indicates that the following 2 character code (hexadecimal) is encoded.

Taking a basic web server file structure as an example, if you have a space in a file name or directory (for example in a portrait photo file path), when that file name is sent out onto the network it will have been encoded so that there are %20 characters where there would have been spaces.

So back to the reverse proxy. Some are configured so that when they receive the URL they scan it for reserved characters. There may not be spaces any longer, but there are now percentage symbols and they are reserved. So a "%" is encoded to a "%25" which means that the space has now been (double) encoded to "%2520".

When the user's web browser receives the URL it runs just one decode on the URL and so rather than getting a space, the browser reads it as a string of characters "%20".

Example:

I have an image file: c:\web\images\portraits\john smith.jpg
The web server is called mypix and the root directory is c:\web
The web server URL for the image file would be http://mypix/images/portraits/john%20smith.jpg as it encodes the space.
The reverse proxy encodes the URL a second time to http://mypix/images/portraits/john%2520smith.jpg
The end user's browser does not know there was an intermediate server that has encoded the string a second time and so decodes the URL to http://mypix/images/portraits/john%20smith.jpg rather than http://mypix/images/portraits/john smith.jpg
As a result the browser sends back a request to download a file called "john%20smith.jpg" rather than "john smith.jpg" ... which is a file that does not exist.

Note: I'm not sure off the top of my head if the double encoding occurs in one direction or two (this might be a configuration setting), but if it is two then this issue could be compounded on the return journey from the user PC to the server (via the proxy) - so " " would become "%2520" for receipt by the web server.

Hopefully that explains what sort of issue can occur with double encoding and how this can sometimes be introduced by intermediate reverse proxy servers. This does not mean that this is definitely your issue and if your basis & network teams didn't get the response in the other thread then the chances are you probably don't have a reverse proxy in place. Without an intermediary to carry out a second round of encoding you wouldn't see this particular issue.

If there's anything in particular in this that doesn't make sense, let me know.

Regards,

Stephen.

Hi,

First of all, thank you for the long reply. Before passing the issue to the basis team, we have debugged the /NAKISA/LHR_ORGCHARTU07 function in the /NAKISA/SAPLHR_ORGCHART function pool with an ABAPer again and realized something that might be the actual reason why we do not get the photo. In this function, there is a IF line(condition) which has the variable NO_URL causes URL not to return as it does in the details panel section. Instead, it returns a "X" default value which is not what we demand. When we remove this X and leave it as blank, the photo also appeared in the left side of the box. Presumably, that X is preventing the function to get the actual URL generated for the photo. From this point, I have two questions to have a solid solution to this issue;

1) Should we put an enhancement point into this system function which will either remove the X from that line and leave it blank or making that condition as a comment line as we have investigated that line has no affect on the processing of the function ?

2) Is there something should be done from NAKISA part to correct this situation ? Because, NO_URL (RFC parameter) is fed from outside of R3 as we investigated the issue with the ABAPer.

Consequently, I am glad that we could have seen the photo on the left side of the box in the end Hopefully, one of these solutions will guide our way.

Regards.

Now you've jogged my memory!

NO_URL was included in 4.1 release to disable portrait photos by default.

If you wish to re-enable you need to look at the relevant data elements.

EmployeeHierarchyDataElement.xml
OrgUnitHierarchyDataElement.xml
OrgUnitHierarchyDataElementForAnalytics_Staged.xml
PositionHierarchyDataElement.xml

In each you'll find:


<importparam>
  <param>NO_URL</param>
  <source>DefaultValue</source>
  <value>X</value>
  <caption><![CDATA[No Picture Url]]></caption>
</importparam>

Also, the views have been disabled by default - see orgchartconfiguration "OrgUnit.xml" and notice the hidden attribute:


<view default="false" hidden="true" hierarchy="OrgUnitTypeOrgUnitHierarchy" submenu="">ou_manager</view>
<view default="true" hidden="false" hierarchy="OrgUnitTypeOrgUnitHierarchy" submenu="">ou_manager_no_portrait</view>

Also check the Position Portrait view is not hidden.

On this last point about the views, see the comment at the top of page 176 in "OrgChart_VSN41_Admin_En.pdf"

Regards,

Stephen

Hi Stephen,

If I got your point correctly, the issue is about enabling the views with portrait or not ? If that is the case you mention, I am working with the portrait views already. If I am wrong, please correct me

What we have discovered in the function module is; NO_URL has a default value and we set a breakpoint at that parameter's line. When we clicked on position hierarchy on NAKISA user interface, the debugging showed us that NO_URL is set to "X" by default. When we removed that X and continued, the photo displayed correctly. So in this case, as far as I understood from your point, I actually want to disable NO_URL because of that default value is preventing the function to get the URL of the image.

Please enlighten me, we are so close to the solution I believe

Regards.

So for the OU Manager view I think it might be that the view (with portrait) itself is hidden. But should be ok for Position Portrait.

NO_URL - yes I'm saying the default is to pass X (meaning "no pic url is returned"). Change the data element to remove this parameter and hopefully it will pass <blank> and you'll get a URL back in RFC.

Stephen

I understand so my situation is not about enabling the views with portrait or not but changing the 4 data elements that you have listed above, right ?

To do that, I should only remove those X's in the line <value>X</value> and after removing it should like below, is that correct ? ;

<value></value>

And one more question, this change should be done under the root folder or the build's own folder ? I am not very well-informed about the file system part so I had to ask.

Regards.

Yes to removing the X.

But never updated the root directory (as when you publish it will overwrite again).

Always take a copy of the file you are changing and put into the .delta area of your build.

Stephen

Thanks a lot Stephen, I appreciate!

I will let you know the result.

Regards.

Hi,

We have tried to remove the "X" from that line in those 4 XML files given above and published the build after that but when I go and check those files, that X value stands still and the pictures do not appear in the box 😕 I have changed the XML files in the directory below (Deneme is the name of my build);

D:\usr\sap\BPD\J30\j2ee\cluster\apps\Nakisa\OrgChart\servlet_jsp\OrgChart\root\.system\Admin_Config\__000__Deneme\AppResources\dataelementconfiguration

As you said, I think it overwrites the X that is located in the root directory. No matter if I have changed the files in the build's own folder or not, it accepts what is written in the root folder which is;

D:\usr\sap\BPD\J30\j2ee\cluster\apps\Nakisa\OrgChart\servlet_jsp\OrgChart\root\XML\AppResources

I believe either I am doing something wrong or Nakisa's standart configuration is not changeable.

Please assist..

Regards.

I recommend training if you are implementing Nakisa and looking to make changes, particularly like this. This will ensure you understand the "why" as well as the "how".

But for the how ... I recommend reading this Wiki article:

How to make changes to customization files in 3.0 SP1 and above - ERP Human Capital Management - SCN...

Unless a file is in the .delta of your build, then when you publish it will not move to the runtime area (..OrgChart\root\XML\...) and hence not affect the end user application when you test (as you have discovered).

Stephen

Hi Stephen,

Even if I am not at that project now, I am on your discussion and problem could about ".delta" folder's tricky..

Does it work now?

Ask a Question

Top Q&A Solution Author

User

Count

110