Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

custom table - delivery class?

Former Member
0 Kudos

I need to create a z-table to list the email-ids that I want to notify to, in case of program errors. Should I make the delivery class of this table 'C'? And is best practise to make the data transportable? Or should my users just enter data in each system.

I am kind of confused...Could any of you please clear me on this concept of Deliver class please. Your help is very much appreciated.

thanks!

1 ACCEPTED SOLUTION

Former Member
0 Kudos

The answer depends on what the business wants. Do they want to directly maintain these entries in the production system? If they do then go with delivery class 'A' and create a table maintenance with required authorization group. This way the authorized users can add/remove new email ids as and when required. So you need to get back to your customer and ask how they want to maintain this table.

You would go for a delivery class 'C' if there is a strict requirement for this table to have same contents in all dev, test and production systems. This is true for configuration tables as you would want the configuration to be same in all systems. A delivery class 'C' table triggers customizing transport request when contents are changed. Hence the changes need to be made in dev system and everytime a change request and TR would be required to move the changes to test and production systems.

That said, if it is possible why don't you create a distribution list containing all required email ids in SBWP and use the distribution list in your program. This way you don't need to create a separate table and maintenance for it. Also if you use SBWP distribution list remember that it has to be maintained directly in the target system and entries are not transportable.

Best regards,

Vishnu Tallapragada

8 REPLIES 8

Former Member
0 Kudos

Hi,

yes it is better to make deliver class as 'C' and better to transport in each clients

former_member205763
Active Contributor
0 Kudos

Whenever you data is static and rarely changing and you dont want user to update the table on a regular basis then create the table with type C so that the entries are created in DEV and transported to PROD.

your requirement seems more suitable to type C only, but every change to this table then may have to go through DEV always.

Former Member
0 Kudos

The answer depends on what the business wants. Do they want to directly maintain these entries in the production system? If they do then go with delivery class 'A' and create a table maintenance with required authorization group. This way the authorized users can add/remove new email ids as and when required. So you need to get back to your customer and ask how they want to maintain this table.

You would go for a delivery class 'C' if there is a strict requirement for this table to have same contents in all dev, test and production systems. This is true for configuration tables as you would want the configuration to be same in all systems. A delivery class 'C' table triggers customizing transport request when contents are changed. Hence the changes need to be made in dev system and everytime a change request and TR would be required to move the changes to test and production systems.

That said, if it is possible why don't you create a distribution list containing all required email ids in SBWP and use the distribution list in your program. This way you don't need to create a separate table and maintenance for it. Also if you use SBWP distribution list remember that it has to be maintained directly in the target system and entries are not transportable.

Best regards,

Vishnu Tallapragada

0 Kudos

> A delivery class 'C' table triggers customizing transport request when contents are changed.

I don't think so. Customizing TRs are raised for client-dependent tables & workbench for client-independent ones!

Delivery Class of a table doesn't determine the type of TR generated. Rather it determines the behavior during Upgrades, client copy etc.(read F1 for further details)

BR,

Suhas

0 Kudos

I don't think so. Customizing TRs are raised for client-dependent tables & workbench for client-independent ones!

Delivery Class of a table doesn't determine the type of TR generated. Rather it determines the behavior during Upgrades, client copy etc.(read F1 for further details)

BR,

Suhas

Suhas,

Did you try? I tried these things long back and documented the behavior.

Delivery class does determine the kind of transport request that will be triggered through table maintenance generator (TMG). Delivery classes A and S will only trigger workbench requests, C, G, and E will only trigger customizing requests and L, W won't trigger any request at all.

That is of course assuming that the "Standard Recording Routine" option in table maintenance generator is checked on. Without this no transport request dialog will trigger in the first place

You are right that the delivery class does determine how SAP categorizes how the tables will be treated during upgrades, but that is not the only function

Though generally workbench requests are meant to be triggered for only repository/cross client and customizing requests for only client dependent obects, in TMG, I can create a table with MANDT assign delivery class A or S and can trigger workbench requests on it. Try it once!

Best regards,

Vishnu Tallapragada

0 Kudos

Vishnu,

Did you try? I tried these things long back and documented the behavior

May be you tried it very long back, indeed. Atleast for releases > ECC6.0 EhP3 client-independent customizing tables prompt for WB requests.

... C, G, and E will only trigger customizing requests ....

Unfortunately you're wrong! Did you check the transaction FILE? All the tables involved are of Delv. Class 'G'; but still when you try to save a logical file it asks for a WB request, ever wondered why?

Still not convinced, check [this|https://picasaweb.google.com/lh/photo/kBwoENEIkUTsGuJUTn9Q5tMTjNZETYmyPJy0liipFm0?feat=directlink]!

Suhas Saha wrote. "Customizing TRs are raised for client-dependent tables & workbench for client-independent ones!"

This was w.r.t customizing tables & not application tables, as you were talking about customizing tables in your previous response.

I can create a table with MANDT assign delivery class A or S and can trigger workbench requests on it.

I know it does. IMHO type 'A' tables are for storing master and/or transational data & it does not make sense to transport these data. For e.g., BKPF is type 'A' & not transportable, but T001 is type 'C' & transportable.

If i want to transport the data across my landscape i would make it 'C' & not 'A'.

BR,

Suhas

0 Kudos

Thank you all very much for the responses to my question. It give me a good understanding of the delivery class and client dependend and independend tables.

Soumya

former_member193284
Active Participant
0 Kudos

Hi Soumya,

Here are few tips on how you can decide which delivery class you should use.

Identify if the data that would be stored in your custom table is changed oftenly? if not then it should be master data. and not customizing.

In your case the email ids of a person may not change oftenly so you can keep it as master data rather than maintaining it as customizing

Also it is recommended to transport the entries but in some cases the business users want to avoid this as if they may want to have access in production to create delete or change entries. so rather than transporting they prefer to do it manual.

So you can probably talk with your team and notify then the advantage of trasporting entries and take their consent before moving the entries through transports.

Thanks