When importing through webservices, for an ImportOption, what is the ItemIndex?

Justin Pohlmann shared this question 2 years ago
Answered

The documentation says: "The index of the item that this option is attached too.". Is that the index of the item in the XML array being sent it? Or is the the resourceId? Or the UUID?


Trying to import with options, and getting a -2 error.

Comments (1)

photo
1

Hello Justin,

Thanks for reaching out with your question. 'ItemIndex' is the index of the item as it exists in the array you're providing to your API call.

Unfortunately, the -2 error isn't very helpful. In case you hadn't found our page of Web Service Exceptions, it indicates an unknown error. Let me know if this answer helps you in the creation of your API call. If you still encounter specific issues we can take a look and go from there.

Thanks,

Ryan

photo
1

Yea, I saw that, -2 errors are pretty much what I get when things go wrong, and cooresponding java.lang.NullPointerException in yellowfin.log.

I was able to get that index set properly for the importoption. If I'm trying to attach a report to an existing subcategory, do I need to have an importoption for the existing category and subcategory? This is what my importoptions look like, with the category and subcategory having the resourceCode of the target server's category and subcategory I want to attach the report to:

array(2) { [0]=> object(stdClass)#577 (3) {

["itemIndex"]=> int(4)

["optionKey"]=> string(8) "CATEGORY"

["optionValue"]=> string(6) "CATP11"

} [1]=> object(stdClass)#576 (3) {

["itemIndex"]=> int(4)

["optionKey"]=> string(11) "SUBCATEGORY"

["optionValue"]=> string(21) "CATPERSONALPORTFOLIO1"

}

Do you see anything glaringly wrong with those?


Thanks!

photo
1

Also, I think the API call erroring out on import may have caused some data corruption. I have some duplicate datasources I went to delete through the admin, and I got the following error:

7c75914338254ae18ce124c3f0b54c86

When I look in the yellowfin log, I see:

YF:2017-11-29 10:17:05: INFO (MIDataSourceAction:execute) - MIDataSourceAction entered

YF:2017-11-29 10:17:05: INFO (MIDataSourceAction:execute) - MIDataSourceAction exiting with action: deleteSource

YF:2017-11-29 10:17:07: INFO (MIDataSourceAction:execute) - MIDataSourceAction entered

YF:2017-11-29 10:17:07:ERROR (MIReportProcess:loadReportDefinition) - Error: java.lang.Exception: ContentManagement record missing for report 61485

java.lang.Exception: ContentManagement record missing for report 61485

at com.hof.mi.process.MIReportProcess.loadReportDefinition(MIReportProcess.java:3123)

at com.hof.mi.util.ReportDefinitionCache.getReportDefinition(ReportDefinitionCache.java:105)


Looks like maybe records got orphaned somehow?

photo
1

Hi Justin,

Thanks for the reply. On your first question, that all looks fine for importing objects into an existing CATEGORY / SUBCATEGORY.

When importing, you'll want to specify 'SOURCE' to assign the View / Report to an existing data source. This should prevent this duplication.

It looks like, according to the error, that these don't actually exist in the Configuration Database. Try cycling the Yellowfin service to see if they remain. If they do, we can look at some back-end work to remove them.

Let me know how it goes.

Thanks,

Ryan

photo
1

Thanks Ryan!

Do I need to add all dependent objects to the export, or if I add the report, will it handle adding the dependent objects automatically when I call getExport?

photo
1

Justin,

I think the function "GETEXPORTDEPENDENCIES" is what you're after in grabbing those. Likely safer to assume the requirement of grabbing them to avoid unexpected behavior during import.

There's likely exceptions to this, depending on the scenario, i.e. whether the source / view exists or is being imported.

Does this help?

Thanks,

Ryan

photo
1

Ya, that confirms what I was thinking about.

One other question I had, in the documentation for the EXISTING ImportOption, the description says

This requries the internal ID of the content you are replacing. For example, if the item is a View, then this value will be an existing ViewId. If the item is a Category or Sub Category it will be the CategoryCode rather than an ID.


But when I send the category code of the category, I get a numberformatexception in the log, e.g.


YF:2017-11-29 13:35:01:ERROR (V4ImportProcess:validateImport) - Error: java.lang.NumberFormatException: For input string: "P1"


Is this supposed to be the resourceCode? Or the resourceId for everything?

photo
1

So I got around this by just not importing categories and subcategories that exist, that seemed to work.

I think I'm really close. Did you have some backendy magic to get rid of those undeletable data sources? I tried bouncing yellowfin and they stuck around.

photo
1

Hi Justin,

You're correct on supplying "P1" as the EXISTING value for a Content Category. This particular error indicates that somewhere along the line the string is being submitted as input for an integer. I'd have to review a full code snippet to attempt to determine where this may be occurring.

I'm glad you were able to work around it by not declaring the Category.

On the note of removing the corrupt data sources, it's possible to remove these by querying the Configuration Database directly. When running any queries directly against the Yellowfin Configuration Database it's possible to cause irrevocable data loss. This process isn't directly supported nor recommended unless otherwise advised to do so. Before running any queries against your Yellowfin Configuration Database, please make sure you have full, up-to-date backups of both your Yellowfin Configuration Database and your Yellowfin Installation folder. This way, if something goes wrong you can revert back to your current state.


I would first see if you're able to alter a property of the Data Source(s) in question. Preferably the name, wherein you can differentiate it from your legitimate data sources. The 'ReportViewSource' table within the Configuration Database contains the Data Source records. You can should be able to manually drop records from here, if identified as problems, and restart Yellowfin to effectively remove the sources.

What it looks like happened here, judging from your error message snippet, is that an import call created the data source, but failed during report import. This associated a report ID with the data source, but didn't create the report ID. So now, when Yellowfin tries to delete the Data Source, it's being told there's an associated report ID, but it's unable to find it!

Have a look through and let me know what you think. There may be alternative methods to overcome this if this process proves difficult to isolate the proper Data Source(s) through.

Thanks,

Ryan

photo
1

Hi Justin,

I wanted to reach out on this and see if you're all squared away.

Thanks,

Ryan

photo
1

Hey Ryan-

Thanks for reaching out! I think I'm getting closer, some of my reports come in successfully, some are erroring out. In the yellowfin.log I see some errors:

YF:2017-12-07 14:55:28: WARN (V4ImportProcess:A) - Unable to locate SourceId for report Engagement Timeline (497128)

are those a problem at all? Do I need to link a datasource to reports, or just to views?

photo
1

Hi Justin,

As long as the Views are tied to the proper Source they should work. Have you tested the report mentioned in the log to see if it runs properly?

Thanks,

Ryan

photo
1

Hi Justin,

I wanted to check in and verify that we're good to mark this as Answered.

Thanks,

Ryan

photo
1

Hey Ryan-

I'm still getting -2 errors, even when the test import works. I've tried to test it with just one report and it's dependencies, but it still isn't working.

I gave up for now, but I'll hopefully circle back to it in the near future. Not sure if it makes sense to open a new question at that point, or reopen this one?

photo
1

Hi Justin,

Let's go ahead and start a new thread with the specifics when you come back around. This will help to specify the thread a bit more.

In the meantime, I'll mark this one as Answered.

Thanks,

Ryan

photo