I'm trying to do a mass update using HR_ASSIGNMENT_API.update_emp_asg_criteria via Web ADI. I've written a wrapper to call the API which works but in some case's when adding a position to a assignment a note is returned saying
"Assignment Budgeted FTE is not equal to position FTE Capacity"

This cause's the Web ADI load to fall. Is there a way around these note's that I could code in the wrapper?

Is the api call actually returning an error status then? It doesn't sound like it should for something like that. Some sort of warning flag maybe, but not an error?

By way of a test, does your wrapper work when called from within a sql environment?

It works without problem when executing the proc using sql but get the following error using web ADI

PQH PQH_FTE_NE_SHARED_POS_FTE_CAP : Assignment Budgeted FTE is not equal to position FTE Capacity.

OK, interesting.

In your wrapper, do you encapsulate the api call in a pl/sql block? Maybe if you do that, you can trap the specific situation and allow it to continue as though nothing had happened?

One possibility might be that the thing that passes the message back to the Web-ADI integrator is not liking the length of the message?

It wasn't in a block, tried it but still no joy.

I've found another instance in create employee API. When trying to create an employee that shares a name with an existing employee I get the following:
PAY HR_PERSON_DUPLICATE : A person of this name already exists. Continue?

It doesn't load in Web ADI as it seems to be waiting for a response?

That's kind of weird...

Would you be happy to post the API wrapper code here?

I've attached the two wrappers one for creating emp's and one for updating asg_criteria

As a possible was around these application cautions. As the load is a one time migration, would anyboby know if they can be turned off in the forms?

If there were, they would most likely be implemented as System Profile Options - I know that such things exist for certain NI number validation rules. Go to the System Profile Options screen in the System Admin Responsibility and look for anything beginning 'HR%'

Having said that, my own personal opinion is that going down this route is a dangerous game to play. OK if you're doing a one-off load into an empty, not-yet-live system, as long as you have a specific step in your transition plan to switch all these checks back on again! The problem is, though, how would you know you've covered all the possible rules the load process is to encounter, until you come to do the load for real? what if you come across a situation for which there is no option, or any other legitimate means to disable the rule?

I do think we need to come up with a way of trapping the message and allowing the process to carry on anyway. If you can post the code items again (I think the issue has been resolved now that prevented me from seeing it the first time) then maybe that will shed some light on matters.

Tried using separate block and capturing the error in a when others exception handler but the handler doesn’t catch it as the standard error message is still returned.
 PAY HR_PERSON_DUPLICATE : A person of this name already exists. Continue?

Just found the following note on matalink. Looks like may not be possible

419797.1

Which states

"For Error 2: PAY HR_PERSON_DUPLICATE : A person of this name already exists. Continue?

Both an employee and contact record have the same last name and first name, which causes a Caution in the Professional User Interface (PUI) and causes an error in Web ADI.during upload.


Fact: Caution and warring messages that occur in the PUI are not supported in Web ADI."

This all sounds very odd to me... The api will do the create or update, but in doing so might or might not set a warning flag. The returned status is still 'success', so no exception activity will occur. When you run the code through a sql harness, it all works fine. In fact, unless you specifically coded for the warning situation, you'd not know the warning occurred. So why does Web-ADI take it upon itself to act upon this warning?

One other question: what kind of integrator are you running this with?

As an aside:

Don't take this as a full-blown peer review or anything like that, but from looking at the 'update assignment' wrapper, I see that you are defaulting the input parameters to null...

You might want to consider the general strategy of how to interpret a null input within your wrapper, i.e. is it really a null, or is it a 'do not change' instruction? If you leave your code as is, it will have the effect of trying to set everything to null that you aren't explicitly setting to something.

Where I have had occasion to do this in the past, I built a procedure to convert a null to a 'do not change' value, and the text '[NULL]' to a true null (just in case the user genuinely wishes to set something to null)

I'll change to hr_api.g_varchar2 defaults. Thanks for tip, always appreciated. As all self taught I get into bad habit's until they cause a fail, then bang my head against a wall for half a day or so wondering what went wrong. So hopefully that tip will save me headache.

It's a create integrator

No worries, always happy to try and help someone who is trying for him/herself to solve a problem.
I do think however that the changing of the default to g_varchar2 might not be enough. If the integrator passes a null from the spreadsheet input, then it will override the default anyway - so it may be that you need to explicitly trap nulls and convert them to g_varchar2 as appropriate.


OK, if possible can you post some more details of the setup of the integrator, e.g. Screenshots or FNDLOAD type extracts?

Been using the HR Seeded integrator template to set up the following:

CT - You were right just using the default to g_varchar2 didn't prevent fields being updated to null, I had to catch and convert.

Cheers again