ā2012 Dec 18 3:55 PM
Hello ABAPers
i am here in a blocked situation could you please help me :
after finishing OSS note manual and automatic implementation
i think i should - before transportation to prod - make an analysis
because i touched SAP's standard ( by adding a field to standard table )
to see what influence will have this modification on my System
Could anyone give some steps to follow to make a full analysis
and the points that i should respect?
Thanks in advance.
ā2012 Dec 19 3:50 AM
Although the risk should be low since the changes are from an OSS Note, it makes sense to double check before moving anything to production. Having said that, I believe the OSS Note you are talking about would already list any foreseeable risks and things to check before transporting changes to PROD.
I don't know what all your Note asked you to change but the one thing you have mentioned is addition of a field to a standard table. One obvious and basic thing you should check is that the table is active and that there has been no loss of data.
Further, it's important to verify that data is flowing to the table without any issues. I assume you would know which transactions are responsible for filling data in the table. So, you should do a thorough testing of that transaction and ensure that the right data is flowing into the table, including the new field.
In case you have any custom programs that write into the table, then you would need to make sure that they are providing a value for the new field (of course, if it's applicable).
You can also do a where-used on the table and go through the objects that are using it and make sure that they are active and don't have any errors. Since it's a standard table, it may be used at a lot of places; if that's the case, atleast do review any custom objects that may be using it.
ā2012 Dec 18 4:08 PM
Which note is it?
If it's a change as recommended by SAP in the note and included in the standard in future support packages, you understand what the change is good for and there are no syntax errors, then you should be fine.
Thomas
ā2012 Dec 18 4:16 PM
Thanks Thomas,
The note is 1571139
and it was delivred in SP Level 7 and i have Level 8
but when the modifided table is used in almost 50 programs
this is the main problem
Amine
ā2012 Dec 18 4:25 PM
I assume it's the other way, you are on level 7 and the note is included in 8. Otherwise it would already be included in the standard and you could not implement it.
Well, it will be standard anyway, now it's your call if you need it now or you wait until the support package upgrade.
Good testing as mentioned by Felipe is certainly recommended.
Thomas
ā2012 Dec 18 4:29 PM
yep,
sorry i didn't pay attention
and i tried this solution too they said
next upgrade will be in 3 months and
this is so urgent
Thank you
ā2012 Dec 18 4:14 PM
You should be able to identify in which scenarios / business process these changes are involved, one simple idea is use "Where is used" functionality in the table that you change.
Once you got the scenarios, the responsible people should perform the tests and check if everything is ok. Generally these steps are part of the IT corporate policy.
ā2012 Dec 18 4:20 PM
Thanks Felipe,
yes i used the "WIS" and the result i get push me
to publish this issue and try to get some help
as i said the modified table is used in 50 standard and specific program
Amine
ā2012 Dec 18 4:29 PM
If you achieved the results that you're looking for applying this note and no issues were reported in quality environment you can use this as evidence.
Off course you could get errors with OSS notes but this note is from 2011 and there are no related notes reporting issues after it implementation.
after a quick research I could find the related notes below, I recommend that you take a look:
| 1. | 0.280 | BC-SRV-COM | 1639715 | SBWP: Counter not displayed | 07.10.2011 | |
| 2. | 0.240 | BC-BMT-WFM | 1634086 | SWPA enhancement: Optimization of Container Persistence | 22.11.2011 | |
| 3. | 0.240 | BC-BMT-WFM | 1658491 | Enhancement SWPA: Long mail title | 20.04.2012 | |
| 4. | 0.240 | BC-BMT-WFM-WLC | 1704891 | WF inbox: Missing task texts in navigation area | 13.04.2012 | |
| 5. | 0.240 | BC-BMT-WFM-RUN | 1685032 | Configuration: Background work items with jobs | 20.09.2012 | |
| 6. | 0.230 | BC-BMT-WFM-WLC | 1640209 | Dynamic columns in outbox and resubmission | 29.11.2011 | |
| 7. | 0.230 | BC-BMT-WFM-WLC | 1571139 | SBWP: Display counter in 'Grouped according to tasks' | 15.04.2011 |
Message was edited by: Felipe Simionatto
ā2012 Dec 19 3:50 AM
Although the risk should be low since the changes are from an OSS Note, it makes sense to double check before moving anything to production. Having said that, I believe the OSS Note you are talking about would already list any foreseeable risks and things to check before transporting changes to PROD.
I don't know what all your Note asked you to change but the one thing you have mentioned is addition of a field to a standard table. One obvious and basic thing you should check is that the table is active and that there has been no loss of data.
Further, it's important to verify that data is flowing to the table without any issues. I assume you would know which transactions are responsible for filling data in the table. So, you should do a thorough testing of that transaction and ensure that the right data is flowing into the table, including the new field.
In case you have any custom programs that write into the table, then you would need to make sure that they are providing a value for the new field (of course, if it's applicable).
You can also do a where-used on the table and go through the objects that are using it and make sure that they are active and don't have any errors. Since it's a standard table, it may be used at a lot of places; if that's the case, atleast do review any custom objects that may be using it.