Migrating from Archived data from one SAP to another SAP system

[Former Member]

Hi Gurus,

We have requirement to migrate archive file from SAP systems A & B to Target SAP system C and view the data in this new system. What are all options we have in this scenario. The archived file will be stored into Opentext Archive server.

Regards

Raja

[benedikt_wagner_mdt · Accepted solution]

Hi Raja,

I used function module ARCHIVE_ADMIN_CREATE_REMOTE to copy the management data from tables ADMI_RUN, ADMI_FILES and ADMI_VARIA from one system into another. I have done this for about 10 archiving runs. Archive files remained in the original storage system. But it should be possible to copy them from one storage system to another if you need and maintain this in the ADMI_FILES data.

Please have a look at the example program I used. Please test carefully!

Regards,

Benedikt

parameters: pa_run type admi_run-document default '123'.

data: lt_admi_run   type table of admi_run,
      lt_admi_files type table of admi_files,
      lt_admi_varia type table of admi_varia.

select * from admi_run into table lt_admi_run
  where document = pa_run.
select * from admi_files into TABLE lt_admi_files
  where document = pa_run.
select * from admi_varia into TABLE lt_admi_varia
  where document = pa_run.

CALL FUNCTION 'ARCHIVE_ADMIN_CREATE_REMOTE'
DESTINATION 'SYS_CLN'
  EXPORTING
    sysid                = sy-sysid
    object               = 'IDOC'
    client               = sy-mandt

tables
    run_tab              = lt_admi_run
    files_tab            = lt_admi_files
    varia_tab            = lt_admi_varia
*   SKIP_TAB             =
EXCEPTIONS
   ERROR_OCCURRED       = 1
   OTHERS               = 2.

[Former Member · Accepted solution]

Thanks Benedikt for your response.

I have some more queries.

Do we need to keep same name of source system for field "Key for archive file" in target system  ADMI_FILES table ? How to mitigate if the same name is used in both systems before migration ?

Do we need to move ADMI_VARIA table ? Since this table stores only variant details , is there any significance of these values in target system?

Regards

Raja

[benedikt_wagner_mdt · Accepted solution]

Hi Raja,

SAP will provide a new number for the copied data to ensure uniqueness. You do not have to care about it (see implementation of ARCHIVE_ADMIN_CREATE_REMOTE):

     ls_admi_files-document = l_counter.
     ls_admi_files-archiv_key+0(6) = l_counter.
     INSERT ls_admi_files INTO TABLE lt_admi_files_new.

     ls_admi_run-document = l_counter.

So SAP will not check if the document number in the files equals ADMI_RUN-DOCUMENT.

I recommend to move ADMI_VARIA because this table contains information about the values in the selection screen when the run was started. This could be very helpful in later times or maybe necessary if you have an audit.

Regards,

Benedikt

[Former Member · Accepted solution]

Hi Benedikt,

We are using OT archive server to store the archive files in both systems. When I change the "Key for archive file" in the target system i am not able to fill the archive information system which is the basis to access the document from target system. Error is as below

Appreciate your response

Regards

Raja

[former_member222508 · Accepted solution]

Hi Raja,

Please try to copy ADMI_RUN as well. I hope it should work then.(I believe you have copied ADMI_FILES and ADMI_VARIA already)

Thanks,

Bala.

[Former Member · Accepted solution]

Hi Bala,

I copied ADMI_RUN as well. Here the problem is if we change the "Key for archive file" name in the target system after copying from source system due to naming conflict , how would the system identify the archive data?

Regards

Raja

[benedikt_wagner_mdt · Accepted solution]

Hi Raja,

did you create the ADMI_RUN and ADMI_FILES entries using the function module or with an own program? Special fields in ADMI_RUN are set by the function module to indicate that these rows are from a foreign system (e. g. system ID). So my advice is to call the function module from the original system via RFC in the destination system using the code above.

Regards,

Benedikt

[Former Member · Accepted solution]

Hi Benedikt,

Now i am trying to run RFC FM in the source system by filling all the 3 tables  but it is not updating ADMI_FILES , other 2 tables updated successfully.

I have not filled anything on the SKIP_TAB and DAVLNK_TAB.

Regards

Raja

[benedikt_wagner_mdt · Accepted solution]

Hi Raja,

sounds odd. What SAP release do you use (source and destination)?

Could you send me the code selecting the data and calling the function module?

Regards,

Benedikt

[Former Member · Accepted solution]

Hi Benedikt,

I am not using program but using Test FM option. One more observation though i had given the correct status in RUN and FILES tables , it is automatically changing to "Unknown status"  in Test FM . Would that be an issue?

Regards

Raja

[benedikt_wagner_mdt · Accepted solution]

Hi Raja,

o.k. could you also send complete screenshot of SE37 Test environment with simple parameters SYSID, OBJECT and CLIENT and also the RFC target system.

I'm wondering about following:

* you select document 98 but use 8 in the tables.

* you speak about "updating" tables. The entries will be inserted, not updated. The next free number will be used in the destination system.

Maybe you could debug the function module.

Status field should be no problem. You cannot fill this due to conversion.

Regards,

Benedikt

[Former Member · Accepted solution]

Hi Benedikt,

Thanks for your support i am able to fill all the tables through program using this FM. Now only issue i am facing is "Key for archive file" is changing as per available session in the destination. This is creating issue while filling info structure for the migrated archive files from Archive server.

If i keep the same file name then it is working.

What is the option we have to keep the same name for that field in the destination?

Regards

Raja

[benedikt_wagner_mdt · Accepted solution]

Hi Raja,

what is this issue while filling the info structure?

Do you pass the source system ID in field SYSID when calling ARCHIVE_ADMIN_CREATE_REMOTE?

I think there are few options to keep the same file name because you have to ensure that you have unique numbers, but you have three systems (two sources, one destination).

* if you look at the two source systems: do you have overlapping numbers?

* if you consider also the destination system: do you have overlapping numbers?

If you do not have overlapping numbers, you could manipulate the numbers in table ARCH_NUM. Set counter to highest number of the two source systems.

But first you should try with standard behaviour.

Regards,

Benedikt

[Former Member · Accepted solution]

Thanks Benedikt. Your answer really helped me. You are great. Appreciate your input and time.

I have one more last question before closing this thread.

When i try to access the FI document in the SARI archive explorer I am getting different output in each system.

in one system i need to navigate 4 screens to display the document whereas in another system it takes only 2 screens.

Is there any special config need to do to display within 2 clicks? I dont want user to key in every time the document number , company code and fiscal year.

Regards

Raja

[benedikt_wagner_mdt · Accepted solution]

Hi Raja,

your welcome. Regarding the display problem you will have to debug what happens.

1. look into table AIND_STR5 using transaction SE16 and select object FI_DOCUMNT. Here you will see the function module displaying an archived document (normally it is FI_DOCUMENT_ARCH_AS_FB03).
2. set a break point in the function module and look if fields are correctly filled (company code, document number, fiscal year). If that is o.k. maybe your screen for transaction FB03 has been changed and the values are not filled in the fields!?
3. If some strange things happen, you could write your own display function (as copy of standard fm) and enter it in AIND_STR5 (using another line number).

It would be interesting to know what happens in your system. Please give feedback.

Regards,

Benedikt

[Former Member · Accepted solution]

We could not able to find the root cause hence we are planning to create our own program.

Thanks Benedikt for all your valuable input.