Error while extensions import via oma

[Former Member]

Hi,

I had tried to import extensions from one server to another with the same cluster, context, directory configurations via OMA import method. But on importing the extensions oma, these extensions have been created in the tool without the attribute database table and attribute display name and for all the extensions, the datatype has been defaulted to string. The import has resulted in an error due to which I am unable to edit any extensions and also unable to create any extensions. Those new extensions have not been stored in the project extension schema but appear under the project extensions list.

Please help to identy what can be done to solve this issue..

Thanks,

Vaishali Soni

[former_member89217 · Accepted solution]

Hi Vaishali,

There are 2 distinct parts to creating an extension in sourcing one is the extension definition itself and the second is the metadata for the database. This actually occurs in 2 seperate transactions and if the metadata part fails, you can endup with just the etension definition piece. What you need to do is either get the logs from the failed attempt and determine what the failure was or rerun the import to get the failures in a new set of logs.  There could be several causes for failure including missing dependent data. For instance if the extension was of type value list, if the value list itself was missing the extension creation would fail. Another cause could be the extension rowsize has been exceeded. In any event you will need the gfailure information in the sourcing log to determine next steps. Once the problem is resolved you can reimport the OMA and things should synch up.

[Former Member · Accepted solution]

Hi Gary,

Thanks for help.

Your guess is right. The import has failed at the dynamic metadata at the database.

Below is the error I have faced during import. Hope this might help you to further identify the issue.

Thu Jul 05 04:44:49 PDT 2012  ....Imported object number 6. Dynamic Class Metadata (system.dynamic_class_metadata) ID: CLASS_NAME = extension.tenant.infydev.contracts.contracttype

Thu Jul 05 04:44:51 PDT 2012  ....Import failed for object number 7. FIELD_TYPE may not be modified.

Thu Jul 05 04:44:51 PDT 2012  # FIELD_TYPE may not be modified.

Thu Jul 05 04:44:51 PDT 2012  ....Imported object number 8. Dynamic Class Metadata (system.dynamic_class_metadata) ID: CLASS_NAME = extension.tenant.infydev.projects.projects%rfxdetails.

I have also attched the trace file and log file for the error and a screen shot of the project extensions list that got created.

Trace.txt.zip

eso.14.txt.zip

[former_member89217 · Accepted solution]

Hi Vaishali,

I am having difficulty correlating the trace to what I see in the screenshot of the project extension definition.   The trace shows a variety of extension definition classes but only a few that are for projects. In your screenshot there are many project extension attributes that are not associated with table.  This seems to indicate this particular import is not the only problem.  are there similar problems in the the other classes as well? or is it only projects?  from the trace I also do not see a reasonable correlation between extension defintion imports and and metadata imports. Maybe you could provide the oma file itself so we can have a look. I'm starting to wonder if the export is the root of the problem.  if you have multiple oma files, include all that you have.  This is a messy situation to recover from.  The only explainable error (so far) is the field type can't be changed. We only allow changing the field type before any data gets saved. after this the only way to cahnge dtatatype is to inactivate the extension attribute and create a new one with the proper datatype.

[Former Member · Accepted solution]

Hi Gary,

It's true that the trace shows a variety of extension definition classes but only a few that are for projects. I had tried to import few more extension classes like agreements, RFx, etc, along with the projects, in the OMA and all of them were successful except the project extension class.

During import, my project extension class had some collection type extensions also apart from the single attribute extensions which failed. On importing this OMA with other extension definition classes along with project extension definition, all the other extension definition classes had been imported successfully and in the project extension definition, the extension collections have been imported successfully. Only the single attribute extensions in the project extension definition class has failed to import with an error about "field type".

Before importing I have not changed the field type of any of my extensions. Also those extensions in the project class which I was trying to import did not exist in the tool earlier.

Just wanted to ask one more question here. Is it possible to open the OMA file in an editible format, i.e. open the OMA in .zip format, open the xml within this zipped folder in the .txt format, make changes to the .txt, save these changes and convert this file back to xml and then to OMA and then finally import this changed OMA again in the tool?

Thanks,

Vaishali

[former_member89217 · Accepted solution]

On the first point, I think we probably need to pick a specific extension in the project class that has failed and try to import that alone and see what the error is. By any chance were any extensions built manually in the target system before these imports failed? Or was there any use of workbook type imports? 

On the second question, where it is technically possible to edit OMA files, it is very tricky buisness and is not reccommended or supported. So the bottom line would be don't edit the OMA. If you need to change the content do so through the modification of the OML query that builds the export.

To avoid modifying the OML query to limit the export package, You might try creating the proper extension attribute import sheet to reimport a failing extension (.xls file) and see what the results of this is.   In general, the best practice for migrating extensions is in fact through .XLS worksheets. This allows for migrating only those extensions that are needed (eliminates all the mistakes and those made inactive.)  If you get some new information around a particular failure or want me to look at a particular .OMA let me know.

[Former Member · Accepted solution]

Hi Gary,

Thanks for the information!

Before doing the OMA import, there were already existing extensions in the target system, few of which were created manually and few others with the .XLS worksheet.

Please find the .OMA attached that I have used for import.

And if you can spare some time, I can show the error through a live meeting.

Thanks.

Vaishali

[former_member89217 · Accepted solution]

Hi Vaishali,

The oma attachment seems to be missing here.  But based on your reply above, I think I see where this fell apart.   You can't reliably use OMA imports after you have created objects manually or through other import means.  Specifically extensions can be problematic.  Consider the dynamic table. When it is created, it assigns a randomly generated table name.  In your case I would bet, there is a reference to the dynamic table in the OMA. This table most likely does not match in the target system. It cannot create a new one in the target system because the table already exists for projects. So the only way this reliably works, is if the target system is not manually configured prior to the initial OMA import.  Bottom line is you need a single migration stretgy and stick to it. Manipulating configurations like extensions in multiple ways will in most cases lead to the problem you are experiencing now.  As I suggested earlier the best way to go in the case of extensions is the .XLS route. Not sure about the status or importance of your target system. If you can't start this over, you could file a ticket and request some SQL to clear out the extension definition attributes that are not reflected in the schema.

Regards,

Gary

[Former Member · Accepted solution]

Hi,

This issue has been solved by SAP support help. Please refer the OSS messg number 624921 / 2012 for further details on this issue. Anyhow, there are few SQL statements that were required to be executed in the source system and then reimport the source system OMA into the target system again.

Below are SQL stmts executed:-

UPDATE <%SCHEMA%>.FCI_SYS_DYN_MEMBERS

SET IS_INACTIVE = 1, ATTRIBUTE_ID = 'BSTATUSUPDATE_BAD'

WHERE UNIQUE_DOC_NAME = -21474835111334125637239

AND ATTRIBUTE_ID = 'BSTATUSUPDATE';

UPDATE <%SCHEMA%>.FCI_DOC_EXT_ATTR_DEF

SET ATTR_IDENTIFIER = 'BStatusUpdate_BAD',

ATTR_DISPLAY_NAME = 'BStatusUpdate_BAD'

WHERE UNIQUE_DOC_NAME = -21474835101334125636846

AND ATTR_IDENTIFIER = 'BStatusUpdate';

ALTER TABLE <%SCHEMA%>.FCI_DYN_$2147483538

RENAME COLUMN BSTATUSUPDATE TO BSTATUSUPDATE_BAD;

UPDATE <%SCHEMA%>.FCI_DOC_EXT_ATTR_DEF
SET DISPLAY_NAME = 'BStatusUpdate_BAD'
WHERE UNIQUE_DOC_NAME = -21474835101334125636846
AND ATTR_IDENTIFIER = 'BStatusUpdate_BAD';

But these SQL stmts can be executed only when the the system is kept down/offline and should be done witht he basis help. One needs to be cautious before executing these stmts.

Thanks,

Vaishali

[vikram_shanmugasundaram · Accepted solution]

Hi Vishali,

In your case the SQL was provided by SAP, so that is ok.

For others, please note these SQL statements SHOULD NOT be executed without consulting with SAP Support. Executing UPDATE or ALTER statements against the database without SAP approval is dangerous and could result in an unusable system. The recommended approach is to work with SAP Support and follow the directions provided as each situation is different. There is no “generic” solution which can be applied across the board for this kind of problem, each needs independent analysis to determine the exact cause and resolution.

Regards,

Vikram

[Former Member · Accepted solution]

Hi,

Yes, thes SQL statements should be executed ONLY on SAP's consultation. These are specific to the error I faced in our system. This is not a general solution for this type of issue.

Thanks,

Vaishali