WebCOBRA.com Community Message Boards

dpbarbella
Posts: 13
Since: 02/06/2008

I continue to receive the error ("The request failed with an empty response") when attempting an import to your API. However, when submitting the same XML through the Management Console everything is fine.

I'm using .NET 2.0 referencing your SystemIntegrator service and running the ImportXMLToWebCobra method.

jwolgamott
Posts: 257
Since: 09/26/2005

Daniel --

I just created a sample app, and have a suggestion for you..

In your settings.settings file, it stores the location of the web service, and it looks like Visual Studio stored it without the SSL part of the URL

If you'll change this to
https://app.webcobra .com/exec/SystemInte grator.asmx

Everything should work for you.

The "empty response" was likely a 301 or 302 redirection to enforce SSL encryption.

jwolgamott
Posts: 257
Since: 09/26/2005

One final note: on the URL entered above, you shouldn't have any spaces... probably obvious, but just wanted to put that out there.

dpbarbella
Posts: 13
Since: 02/06/2008

The EXECUTE permission was denied on the object 'SystemIntegratorSecurity', database...

Does this mean we need to setup permissions for the SystemIntegrator WS in some way?

jwolgamott
Posts: 257
Since: 09/26/2005

It looks ilke we had denied permission to the system ingrator webservice inadvertantly after our migration. This only affected the automated webservice -- Uploading the file manually through the system would have worked.

If you try again, it will be able to authenticate your request.

dpbarbella
Posts: 13
Since: 02/06/2008

Server was unable to process request. ---> SQL Exception 229 caught on procedure SystemIntegrationUserKeys. Error: The EXECUTE permission was denied on the object 'SystemIntegrationUserKeys', database...

New Error Msg

jwolgamott
Posts: 257
Since: 09/26/2005

OK, I ran through an entire process and logged which procedures needed to be granted execute rights for you.

You shouldn't have anymore 229 execute permissions errors from now on.

dpbarbella
Posts: 13
Since: 02/06/2008

Thanks for all your assistance :)
I think we are almost there.

ERROR: /WebCobra/SecurityLogin/@Administra torLoginCode not supplied

I have included the 'SecurityLogin' node with the correct data. NOTE: our username is 2 words separated by a space.

jwolgamott
Posts: 257
Since: 09/26/2005

Excellent! it sounds like the XML file you're sending across doesn't have the correct formatting.

You can test this be sending in just a normal XML file that doesn't do anything. Step 1 is for it to authenticate you.

Here's an XML stub that I've changed my password with... does yours look like that?

http://s3.amazonaws.com/devcenter.w ebcobra.com/thread46-securitylogin. xml

(You might have to remove spaces in the link)

(And the username with a space shouldn't matter)

dpbarbella
Posts: 13
Since: 02/06/2008

Tried the 'Do Nothing' version of the XML with new results...

Error: /WebCobra/SecurityLogin/@Administra torLoginCode not supplied

However I have supplied the correct authentication and the XML structure appears fine.

jwolgamott
Posts: 257
Since: 09/26/2005

Do you feel comfortable posting a link to your XML that you're sending in? Make sure you XXXXX out your password.

Or, you can just email the XML document to spt@travisoft.com --- paste in the link to this thread and it'll get sent over to me and I can take a look.

It seems very likely that the formatting is slightly off of the XML document, so we should get an answer to you very soon.

jwolgamott
Posts: 257
Since: 09/26/2005

I received the XML you sent to spt@travisoft.com, and when using it I don't receive the same message you're receiving.

I receive that the credentials aren't valid, which of course they are not because of the XXXX on the password.

I've uploaded the XML uploader that I used to validate the service.

http://devcenter.webcobra.com.s3.am azonaws.com/XMLLoader.zip

You will probably need to strip out and spaces in the link --

When I used your XML and a username with a space in it, it worked perfectly.

Would you confirm for me that you still get the "not supplied" error?

The next step will be for us to get your actual password, but I'd like to avoid that if possible.

dpbarbella
Posts: 13
Since: 02/06/2008

Thanks for the code snippet...

The problem with my code was using the 'CreateElement' method to create the XmlElement. I used the 'DocumentElement' property per your example and same code works fine.

jwolgamott
Posts: 257
Since: 09/26/2005

Thanks for including your solution to the DevCenter --

The problem may have ended up being an InnerText vs OuterText situation. So the string containing the XML, as received by the WebCOBRA webservice, did not contain the outer WebCOBRA node.

dpbarbella
Posts: 13
Since: 02/06/2008

ERROR: Module Company threw error: Edit Mode requires a User Defined Key!

Do ALL WebCobra records require a UDK for the service to work?

jwolgamott
Posts: 257
Since: 09/26/2005

It depends on what you're trying to do. The most used case is adding a Qualified Beneficiary. When doing that, you'll need keys for:

Client/Employer (Company)
Sponsor(s)
Benefit Plan(s)
Departments (if using)

dpbarbella
Posts: 13
Since: 02/06/2008

Can you supply us with an XSD schema for your import xml?

jwolgamott
Posts: 257
Since: 09/26/2005

At this time we don't have one -- but I think it's an excellent idea.

It'll be on our list of resources to make available to developers.

The best thing we have now are the examples in IT Resources.

dpbarbella
Posts: 13
Since: 02/06/2008

The sample 'Add QB Groups' shows attributes with values of {EmptyString} -> i.e. MonthsOfCoreCreditableCoverage=""

- What happens if these attributes are left out of the posting XML (as with null)?
- Do they have default values (ints & dates etc.)?

Thanks,
Dan

jwolgamott
Posts: 257
Since: 09/26/2005

I can understand why you were confused on that! I had to look it up myself.

The Core Creditable Coverage fields are only used when adding current Employees.

When adding a DOL Employee through the system, it will ask you if you want to set the Core Creditable Coverage date for the employee. If it is set, then the "COBRA Coverage Confirmation" will print out along with the COBRA General Notice, which is the DOL Notice to newly covered employees.

The fields below only apply to DOL Employees:
MonthsOfCoreCreditableCoverage="" DaysOfCoreCreditableCoverage="" CoreCreditableCoverageStartDate="" MonthsOfPreExistingConditionMaximum Exclusion="" DaysOfPreExistingConditionMazimumEx clusion=""

Bottom line -- just remove the attribute completely if you're adding or manipulating QBs.

Hope that helps!