%SEQNUM getting reset on server restart

[Former Member]

Hi,

I am using %SEQNUM as a suffix to filename in an SFTP adapter. It works fine and assigns a unique number to the filename. However, whenever we restart the server, the counter gets reset and starts from 1 again. This is creating problems on the target side. Any ways I can avoid the counter reset?

Thanks,

Ravi

[former_member182412 · Accepted solution]

Hi Ravi,

If the source is ERP system then generate sequence number using number rage and include in one of the field in the message structure, using dynamic configuration you can build the file name in the mapping and send it to receiver. I have done like this in most of my developments.

Regards,

Praveen.

[Former Member · Accepted solution]

Thanks for the suggestion Praveen. I am exploring this option with the ABAP team. If they can send across a number, I can then use variable substitution to append it to a filename.

[Former Member]

Hi ,

I have a scenario from file to idoc. I want to use sequence number %SEQNUM as a suffix to filename in FTP adapter. It has to assign a unique number to each file name. May I know how to do?

Thanks &  Regards,

Dheeraja

[Former Member]

Hi Ravi,

Can you try NRO (Number Range Object).Where you can generate the a unique number for the field and you can go ahead with variable substitution to prefix the file name.

This is a B2b addon.

If you migrate it to Single stack ,even then you will have no issues

Maintaining Number Range Objects - SAP NetWeaver Process Integration, business-to-business add-on 1....

Regards

Advit

[Former Member]

Thanks for the inputs Advit. We do not have this B2B add on installed on our server at present and I forgot to mention that we are already on a single stack server. But, I believe it will be much easier for ABAP to generate a number using NRO and supply it in a field to PI.

[vicky20691]

Hi Ravi,

2 solutions except the usage of %SEQNUM

1. In the ERP system have a table storing index. Create an RFC and do RFC lookup to see last number in the table and increment one and give back to mapping and then do it via dynamic configuration.

2. file lookup reading the last file name placed at the directory and then in mapping handling it.

Otherwise all types of counter will reset after server restart and only option left out is NumberRangeObject

[iaki_vila]

Hi Everyone,

If the PI is a dual stack system, another solution could be to use an ABAP mapping and to use the ABAP number range objects. May be this is not a good idea because the PI seems to go a single stack architecture, what do you think?

Regards.

[vadimklimov]

Hi Iñaki, all,

That is a valid option, and will require less development efforts since ABAP number ranging functionality is already there in ABAP stack. But it looks like a fast win solution for me - as you already mentioned, PI/PO product roadmap is to move to Java only, so any dependency on ABAP stack functionality will cost extra efforts in its migration to Java in the future. Having this in mind and understanding this is a newly developed mapping, I would personally suggest developing it using Java stack functionality right from the beginning, in order to avoid future migration efforts (redevelopment - no automatic migration from ABAP mapping to Java mapping, retesting, etc.). But surely the option proposed by you is a valid technical alternative.

Regards,

Vadim

[former_member186851]

Inaki,

But in future if upgrade is happening to single stack it will be stop back right?

[former_member186851]

Hello Ravi,

Its a normal behaviour and I  guess you can't reset it.

[Former Member]

Is there another option to do this apart from %SEQNUM? Something that does not reset the counter?

[former_member186851]

Hello Ravi,

You can try using ASMA option and assign counter in the mapping.

But if you do a system restart I guess that also will be reset to intial value.

[vadimklimov]

Hi Ravi, Raghuraman,

This requirement can be achieved in case the counter is persisted somewhere and retrieved / incremented in a synchronized way. Most straightforward option would be to store counter value in local database table, alternatively this can be stored in an external storage system. Later on, the counter value can be retrieved from within mapping and used when constructing value of a file name passed to a receiver channel as adapter specific message attribute.

Drawback of this solution is performance impact: even if the counter value is stored in local database, such design will imply necessity of database lookup and value increment, which will have impact on overall message processing time. If the counter value is stored in an external system, then performance impact is likely to be even more noticeable.

A good example of this approach can be found in already existing functionality of a Java IDoc adapter: for IDoc receiver communication channel, it is possible to enable an option for auto numbering from database, which is used to generate consistent sequential IDoc numbers for outbound IDocs. Mechanism behind this option is exactly the same as described: a IDoc number value is persisted in local database, and every time a new IDoc is generated, corresponding value is retrieved and then incremented. This approach guarantees that even after application server or the whole PI system cluster restart, numbering will not be corrupted / initialized and will continue consistently respecting previously used numbers. Negative performance implication is also there and is a major reason why SAP doesn't recommend to enable this numbering approach as a common solution, but only if it is really required.

Regards,

Vadim

[Former Member]

Thanks for the detailed explanation Vadim. Does PI provide a way to store values in a local database table or does it require custom JAVA coding?

Also, how big a performance issue would it be if we do go ahead with this approach?

Appreciate your help on this.

[vadimklimov]

Ravi,

Out of the box, SAP application server Java / PI applications do not provide such functionality as number range objects, so it will be necessary to implement it using custom development.

Regarding performance implication, there are no any specific figures since they will highly depend on:

• Overall workload on application server and database server;
• Concurrency of executed scenario. To keep sequence numbering consistent, access to the counter in a database shall be isolated - for example, by means of usage of synchronization in Java. As a result, if there are several concurrent messages being processed and they all come across necessity of accessing the counter value at the same time, only one of them at a time will access the counter, others will be waiting until they can access the counter, too;
• Approximate overall message processing time. If it is significant, then extra overhead caused by local database access to the counter value, is likely to be relatively small in comparison to total message processing time.

Regards,

Vadim

[former_member186851]

Good Infy Vadim..Thanks ..

[Former Member]

Thanks for your inputs. I am exploring other options for now that allow  me to retain the counter even if the server is restarted.