Enabling an SM30 maintenance view for multiple users

[jrg_wulf]

Hi everybody, this is about how i got an SM30 maintenance tableview, to accept changes from multiple users at the same time.

It's my first ever blog, so don't expect too much.

Maybe I should start with the admittance that DDIC related development is not my field of experience – but nevertheless, I'd like to share the following, because a reasonably thorough search on SCN didn't bring any satisfying result.

Tableview V_T001B_COFI is a maintenace view that allows users, to assign timeslots for accepting posts, depending on various key values. The view features a subset of the table entries of table T001B.

When the request was brought to me, that the maintenance of posting periods in tableview V_T001B_COFI should be enabled for multiple users at the same time, I started to search SCN for similar threads. That's where I came across this one.

The outcome however, was not satisfactory, since any number of users could have made concurrent changes, leaving the lastone to press 'SAVE'  as the winner.

So I started to reanalyse the problem.

I would need to create key specified locks.

My first impulse was, to create a new maintenance dialog, complete with an enqueueing object, specifically taylored to my needs – that is, locking entries keyspecific.

The maintenance dialog would then have to ensure, that no two users could maintain the same entries. Thatwas the easy part, as far as the maintenance in my own dialog would go.

In addition it was necessary, that any maintenance started by using the standard view (V_T001B_COFI) would still prevent any other user from editing any entry - whilst on the other hand, the key specific  lock would have to prevent the standard maintenance as well.

I knew that I could achieve that, by cleverly combining the use of the FMs to be generated by the enqueueing object, together with FM 'ENQUE_READ'. But still it felt clumsy.

So I started to reanalyse the problem.

I didn't need to have control over every single tableline to be locked seperately – a subset, in this case by tablefield BUKRS would be completely sufficient.

And there it was – the keyword subset. I remembered coming across in DDIC, when building a maintenance tableview.

So my new aproach started by copying tableview V_T001B_COFI to Z_T001B_COFI, with the only difference , setting the maintenance attribut (RDONLY) for viewfield BUKRS to 'S'.

Following that, I created a maintenance dialog without any fancy stuff.

When I started the tableview Z_T001B_COFI, a popup dialog prompted me to provide the variant(BUKRS) and the next thing was a maintenance screen with only those entries, matching the variant.

A quick glance on the enqueued object showed the difference. Where the standard View had produced an entry, specified only by tablename, client and record type, there was now the variant as additional discriminator.

A little bit of testing revealed, that all my preliminary enqueueing requirements where fully met. Without any additional enqueueing object or  modification, the request was fullfilled.

  Mission accomplished :smile:

Sometimes, it pays to think twice before starting to code and for me, it signalled that I should get myself a bit more into DDIC.