Resource OBS/ Managing daily changes

[Anon Anon]

We have an ongoing problem with maintaining our xx Resource OBS. Every day we receive an import from our HR system of new starters, this import will provide the full resource OBS which can be seen in an individuals Rsce properties. This is ok. Also every day the same import will 'advise' us where someone has changes manager or team, thereby affecting their existing rsce OBS. To support all this information we receive two reports from our datawarehouse showing where no OBS is set in Clarity and where a changed OBS does not match the users record. This all represents an administrative nightmare as I then need to go into Admin/ OBS/ xx Resource OBS and either move people around or add them - this takes time and any errors are soon seen in timesheet approavals, etc. My question is how can I automate 'shifting' this information around. I know datamart extraction could help (seen in another thread) but this would need to be a daily task.

I have limited access to creating SP, triggers, etc as we have just migrated to On Demand, and I don't quite have the free reign here as I have had in the past. Any help would be v. much appreciate. Brendan

[Anon Anon]

You can assign an OBS unit to a Resource record through XOG (and also remove (blank out) the OBS).

So you could implement a solution that looks at your extract file and generates the required XML and passes calls the XOG webservice (all of which can be done onDemand).

[Deactivated User]

The way I see that is you would get the new hires with their data as a file.
Then you would supplement that with the XML attributes for those and the required fields and their values and create the xml input file for XOG
For changes and exceptions you would need a file again, but you would need to read the existing data for the required fields so that you can write that back and update those records with the correct OBS data.

When you create the environment for that it will routine.

I would not do any of that directly to the database on premises or OOTB.


Martti K.

[System]

Hi,

Did the solutions offered help resolve your issue? If so please mark as Solution Accepted.

Thanks!
Chris

[Anon Anon]

Hi All,

Some clarification on the issue. the inbound xml file does the following correctly:
<?xml version="1.0" encoding="UTF-8"?>
<NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_user.xsd">
<Header action="write" externalSource="NIKU" objectType="resource" version="7.5.3.3546"/>
<Resources>
<Resource employmentType="Employee" externalId="100001"
hireDate="2010-03-22" isActive="true" resourceId="100001" username="monicam">
<PersonalInformation
emailAddress="[e-mail]"
firstName="Monica" lastName="Maldonado Cruz"/>
<ManagementInformation/>
<CustomInformation>
<ColumnValue name="dh_primary_language">EN-GB</ColumnValue>
<ColumnValue name="dh_line_manager">hilaryw</ColumnValue>
<ColumnValue name="dh_known_as">Monica Maldonado Cruz</ColumnValue>
<ColumnValue name="dh_cd_off_loc">Cinti</ColumnValue>
<ColumnValue name="dh_cd_global_loc">United States</ColumnValue>
<ColumnValue name="dh_grade">Grade 2</ColumnValue>
<ColumnValue name="dh_reg">USc</ColumnValue>
<ColumnValue name="dh_sect">ManPrac</ColumnValue>
<ColumnValue name="dh_ser_line">Comms</ColumnValue>
</CustomInformation>
<OBSAssocs>
<OBSAssoc id="dh_res_obs" name="dh Resource OBS" unitPath="/mycompany/SH/SA/MN/TG/JC/HM/"/>
</OBSAssocs>
</Resource>

When I look at the users resource record (Resource properties Main) the dh_res_obs is correctly populated, but when I look at the physical structure for this resource on the dh_res_obs / units (Admin/OBS) it is not there, so it exists but not at the same time. So I'm still left with having to add new users or move people around as the company changes. Obviously if the data does not physically appear in the Admin/OBS, then the ramifications are extensive - not alligned to manager for timesheet approval/ security access to various portlet pages/ objects/ sub-objects, etc. Is there some mechanism whereby as the new dh_res_obs comes it wil 'update' the backend automatically. Thanks in advance for any thoughts/ suggestions

[Deactivated User]

That is the way I have always done.
Never really paid any attention to associated instances to an OBS unit on the admin side.
Though once looked at that and found out in that case that when clicking add on an OBS type where there was the Add button, all the resource where not displayed (counting the ones already asscoiated and the ones not asscoiated).
However, in spite of that never had a problem with the OBS base rights. They are always according to what was specified in the XML file.

Did you verify that the OBS based rights don't work for an instance which has the OBS path properly displayed on application side but not listed as an associated instance on admin side?

The systems I have looked at have been always with just one partition.
You don't have partition in your XML file. Do you have partitions? and are partitions supported in your version of Clarity?


Martti K.

[Anon Anon]

Hi Martti K.,

To answer your question, no we do not use partitioning, and am unlikely to go down that route. But saying that it is likely that we will be developing the system to enable specific (Resource OBS groups) to see specific sub-objects/ sub-pages etc. But the main issue is that 1. I have always been told/ taught that you 'must' ensure the Resource OBS is correct as this is the central pillar of the system and all access/ security permissioning is derived from this. In our case we use the OBS Unit heavily for timesheet approval:

Access Right OBS Unit OBS Association Mode
Resource - Enter Time dh Resource OBS:Manager X Unit only
Resource - View Book dh Resource OBS:Manager X Unit and descendants
Resource - Approve Time dh Resource OBS:Manager X Unit and descendants

so if a resource is not defined on the OBS Unit, they do not appear to the manager, and this then gets raised as an issue with our service desk, which then means more support work and user perception of a poor system (a hurdle to overcome). So have I been wrong in my belief of what and how important the Resource OBS is or that I should not be concerned as the XML input is sufficient and the system is behaving as it should.

Thanks

[Deactivated User]

If you are not using partitions then the resources, the user doing the XOG write and the user looking at the resources and the users with rights to resources being in different partitions is not the explanation to what you experience.

If the resource not associated with the OBS properly then the OBS base access rights don't work and has the consequences you point out.

I have not explored the uniformity of the OBS association between the application and the admin side, but have been satisfied when the application side displays what is desired and the XOG write does not give an error.
Have not had any complaints either from the user about the rights working as designed.
Can't explain the difference either, though the queries on resource properties page and OBS unit associated instances page are different.

That is why I asked if you have verified whether or not the rights work as designed when there is a difference between the application and admin side.

This is something for somebody who knows the inside of Clarity deep enough.
You could open a case with support: XOG in resource OBS path, no error, OK on resource properties, resource not listed as associated instance in the admin tool OBS unit properties page.

Martti K

[Anon Anon]

brendanj1 wrote:

.....but when I look at the physical structure for this resource on the dh_res_obs / units (Admin/OBS) it is not there...

Are you really sure? I know that when you look at the "attached instances" in the admin tool they do not appear straight away, you have to set the object type and perform an explicit filter for them before you actually see them?

Like Martti's comments - I've never had a problem with the XOG setiing up this data (and if you can see the data in the Resource record but not in the admin tool then that is some sort of BUG I would suggest - if you are really sure that this is the case then what exactly is on the database (the PRJ_OBS_ASSOCIATIONS table) - I can't imagine what else would be going on that could cause this sort of problem?

:wacko:

[Deactivated User]

On admin pages the query goes to PRJ_OBS_ASSOCIATIONS (you only see the instances associated to the unit) while on application side the full path is displayed and therefore the query has to get the parent units as well.
Another option to bug is corruption.

Martti K.

[System]

Hi Breandan,

If this is still an issue you might want to log it with Support and then post the resolution here.

Thanks!
Chris