With a resource integration process, we have multiple issues where resource fields are not getting updated properly. The issue is happening with booking manager field update, resource calendar update.
I've attached the XML format used in resource XOG.
resource XOG :
<NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_resource.xsd"> <Header action="write" externalSource="NIKU" objectType="resource" version="18.104.22.168"/> <Resources> <Resource bookingManagerUserName="AAA" employmentType="BBB" externalId=" " hireDate="CCC" includeInDatamart="true" isActive="true" isExternal="false" resourceId="DDD" resourceType="EEE" terminationDate="FFF" username="GGG"> <PersonalInformation emailAddress="HHHH" firstName="III" lastName="JJJ"/> <ManagementInformation availability="KKK" inputTypeCode="Regular" openForTimeEntry="true" trackMode="PPM"/> <FinancialInformation> <SupplementalInformation active="1" department="***" location="Canada" resourceClass="RES" transactionClass="Labor"/> </FinancialInformation> <OBSAssocs complete="false"> <OBSAssoc id="financial_loc" name="1 Financial Location" unitPath="YYY"/> <OBSAssoc id="financial_obs" name="2 Financial Department" unitPath="***"/> </OBSAssocs> <Calendar baseCalendar="ZZZ" resetCalendar="false"/> </Resource> </Resources> </NikuDataBus>
Please help me with the root cause of the issue as I've confirmed that for booking manager field, it's the user name passed in and similarly with the resource calendar too. The GEL log is returning appropriate value. But it's failing only in XOG update.
Thanks in advance.
When I read out a resource from 15.2 which has no booking manager assigned I do not get the bookingManagerUserName tag, just managerUserName
I do not see it in the sample write file either. That suggest to me that it is not supported for the XOG client.
But I do see it in resource.xds which on the other hand suggest some level of support.
When you read out a resource which has booking manager assigned do you get that in the output file.
Do not see anything wrong with the Calendar line.
Hi urmas, below is the sample resource XML output i get when run for a resource read with booking manager field filled in:
<NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_resource.xsd"> <Header action="write" externalSource="NIKU" objectType="resource" version="22.214.171.124"/> <Resources> <Resource bookingManagerUserName="XXXX" employmentType="EMPLOYEE" entityCode="YYY" externalId=" " hireDate="ZZZZ" includeInDatamart="true" isActive="true" isExternal="false" managerUserName="XXXX" resourceId="nnnn" resourceType="LABOR" username="nnn">
On the calendar issue, we are trying to update calendar from A to B and that is not happening.
Did some testing on my 15.5 where I can assign booking manager GUI (on that 15.2 above I could assign one in the GUI)
I still do not see the bookingmanager tag in the sample XML file, but when I read out a resource which has a booking manager, that is in the output file.
No problem changing that with XOG
The same thing with Calendar. Can change the calendar with XOG.
The simplest possible things are typo in the calendar name and inadequate rights.
Can the user with which you do the XOGing change the booking manage and calendar in the GUI?
Hi urmas - I tried to XOG in for single resource too. Both booking manager and calendar update is happening appropriately. But when ran in my process, which reads in N number of resources, it fails to update these fields. The spelling looks good and the XOG is done with Admin login. So, there is no access issue.
Even with Gel Out, I see no issue with data being passed on. But the update is not happening for these 2 fields.
"the XOG is done with Admin login. So, there is no access issue."
You need to check this - "Admin login" usually means the ability to administrate the application, it does NOT necessarily mean the ability to affect all application data, further functional rights are needed to do that (such as booking rights, edit rights to objects and so on).
(Certainly in the case of the standard "admin" user, performing XOG as "admin" is not a guarantee that the functional rights required for the XOG will be had by the XOG process - its a common misconception)
Dave_3.0, Thank you for the response! I've confirmed that the admin login is having all associated access to update resource details in Clarity.
urmas : The calendar change is not happening because of vacation loaded onto the resource calendar. The issue is that the XOG update on resource's calendar will not happen unless we wipe off the vacation loaded onto the resource's calendar. Whereas at the front end, you can still edit the resource's calendar without affecting the vacation loaded. This is defect with XOG for resource calendar update.