Source system changes impact on BI system

Hi All,
I would like to know is there any work around if source system connected with BI changes. In our environment BWQy 100 is connecte with ECCQ1 100, now bais team needs to copy ECCQ1 100 to ECC2 Q100 and free ECCQ1 for some reason. And asking BW team use ECCQ2 as source system in future.
In this case we need to create new transformations and lot of work involved. Is there any work around to avoid creating transformations for new ECCQ2 system (like SID renaming etc).
Please adivise here how to handle this situation with minimun damage to system, for sure we can't use any more ECCQ1.
All useful threads get awarded...
Best Regards
Edited by: VENKAT78 on Aug 25, 2010 2:36 PM

try this it might help.
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/805eefcd-5428-2d10-c0ab-dc27a95b2c81?quicklink=index&overridelayout=true
Ravi

Similar Messages

ChaRM:System Change Option

Hi Team,
I have activated CHaRM BC sets and created maintenace project. The mainteanace cycle also created successfully. But in the t.code /tmwflow/cmsconf, in the "System Change Option" tab, no systems are displayed. How to bring the ChaRM client, DEV,QA &PRD systems (satellite systems) in this tab.
Note; I am working in SAP EHP 1 for SAP Solution Manager 7.0, ST: SAPKITL433
Thanks.
PSK
Edited by: psk.psg on Oct 6, 2010 7:46 AM

Hello,
Have you completed the following steps in SOLMAN
1) In SMSY creation of RFC connection to the required systems like for CHARM consider you have 3 systems , Customizingg, testing and prod then you have to create the RFC connection to all the 3 systems for particular client.
2) In SPRO in SOLMAN have you Activate Integration with change request mgt
3) Also I hope you have configured STMS properly and distributed the STMS.
Best Regards
Shishir H D

Standards around source system changes

Hello,
This is a general post around good practices to catch source system changes before they impact universes and reports
We have several universes built on source systems and generate user reports
The challenge we face is that there are many changes to these source systems that end up affecting the schema or flow of data. Source teams operate on a best endeavors policy to let us know if any of these impact universes/reports, but many times we discover the impact after the change.
Is there a way to design an automated check or process to proactively check or let us know whenever underlying source systems change from a BO universe stand-point? Are there any tools that can flag such concerns?
I am aware that this is a fairly open question, i am hoping to get advice from seasoned gurus who might have been in similar situations.
Regards

R S,
The only thing I can think of, is not using the same database as your source systems uses.
Instead, use data services to export the data to your own database, specific for reporting. And inside DS you can make it send out emails whenever something did not go as expected (table change, data type change, table renamed).
Your load process from the system database will stop when something like this, but at least it won't effect the reporting side (BO).
This idea on it's own is an entire project and a big one, so I don't know if would be what you are looking for.
Best
Leandro

How to transport FM retraction configuration if source-system changes?

Hi experts,
I have configured FM retraction in ERP through SPRO connecting it to my Dev source system in my Dev ERP. What do I need to do to transport this configuration to my production ERP and make sure the BI source-system changes from Dev to Prod as well? Is there some kind of souce-system mapping as there is in the BI side for the extraction?
For example, I have everything set-up for source-system BWD and I want it to change to BWP when I transport the configuration from ERP dev to ERP prod.
Thanks
Edited by: Pedro Fontes Pais on Dec 2, 2008 6:36 PM

Hi Christian,
Thanks for your reply, but I didn't get anywhere in OKE7 & OKE8 to include the credit records I made in KSAZ in a Transport.
Can you elaborate it more.
Thanks
Amit Goyal

Impact of changing XI 3.0 System Timezone

I am currently analysing the impact of a change of an XI server's timezone from local time (Melbourne Australia GMT10 and 11 for Daylight saving time) to UTC (or GMT0). The XI system is integrating SAP and non-SAP systems running around the globe with the majority of those systems running in their local time zone. The production instance has been running for a few years and has about 160 integration scenarios.
I am looking for information relating to:
   u2022The potential impacts of a time zone change of an XI system (on interfaces, support processes, general Basis considerations).
   u2022Approaches for analysing the impact of the change (i.e. do we need to go through every interface to search for time related mapping and config elements)
   u2022Approach for implementing the change

HI
u2022The potential impacts of a time zone change of an XI system (on interfaces, support processes, general Basis considerations).
Hi Time zones can effect if you have a time based triggering or prioritizing done in any of the developments over the system.
u2022Approaches for analysing the impact of the change (i.e. do we need to go through every interface to search for time related mapping and config elements)
Unfortunately yes you need to check at every interface for time related mapping. For example - Time formats, system time, Time greater than or Less than involved
u2022Approach for implementing the change
Approach can be.
1. Check out all the dependencies you have on time.
2. Prioritize the impacts on business production data
3. Plan for implementation
4. identify the changes
5. Implementation Drill. - If you have load balancing involved in landscape you can go one by one on PI(actual & Load balance)
6. System up
Thanks
Gaurav

Source system changes in current Portal

Hi Friends!
We have SAP BI 7.0 for several countries. Now, the company is thinking about create a "new instance" (copy of the original) in the same server, separeted by region (because days ago, create a new instance in ECC too)
Then, I think that in the new BI we will work like we have a new source system...
a) What will happend with the queries and wad in portal? do I need publish them again?
b) is enough if I change the sourcesystem in portal? how/where I can do it?
c) is necessary or good idea create a new portal instance for this bi new instance?
Thanks a lot for your expert opinion!

Hi,
You can keep the same portal, no need to create separate portals. You just need to create new systems for each additional BI system you create, then give those systems a different alias (perhaps by region like SAP_BW_US, SAP_BW_UK etc...). Then the reports that you have defined in the portal just need to be changed to point to the new systems you created.
Hope that helps,
Simon

SMSY Data Source changes after performing Managed System Config

Hello everyone,
I am working with Solman EHP1 SPS26. I have setup up my central SLD to push system data to my Solman local SLD which is then retrieved from Landscape Fetch to SMSY. Initially, everything seemed to be working and all data sources reported SLD.
However, once I performed the Managed System Confirguration wizard for a particular technical system, that systems data source would change to TMS/RFC under SMSY. It's actually not even that consistent. For example, the server says source is RFC, the product system says TMS/RFC and some of the product instances still say SLD.
Is this normal for this to happen after connecting a managed system? Will these systems still be updated via the SLD considering SMSY_SETUP is configured to use the SLD?
Anyone's help would be greatly appreciated.
Alex

Hello,
If you notice in SMSY this is not an editable field.
It is reporting the last datasource used.
Thefore when you made a change via managed system setup that became the last data source used.
So yes it is normal to see this change.
If you have configured the datasource to be the SLD, it should continue to update these systems.
Where you need to watch out is making manual changes in SMSY, as the SLD can view this as a different system to the SID it knows and will generate systems with known SIDs appended with a suffix variable to distinguish it, as the SLD will not overwrite manual changes, and will create new systems instead.
But the field in SMSY reflects the last data source used.
Hope this helps some.
Regards,
Paul

Source system change urgent

Hi,
I have my BW dev cltn connect to source system 630 ..now the client 630 has been dropped and it has to be connected to 650...what sholud be my steps...i ahve seen BDLS transaction but can any 1 who has done it b4 guide me.
Thanks
Prashant

hi prashant,
check this out.
Note 886102 - System Landscape Copy for SAP BW 2.X, 3.X and NW2004s BI
Fresh source system clients in production BW system
Note 195610 - Logical system name conversion in T000
Note 121163 - BDLS: Converting logical system names
hope it helps,
regards,
Parth.

PLEASE HELP ME TO FIND THE SOLUTION REGARDING "LOGICAL SYSTEM CHANGED"

HAI EVERYBODY,
PLEASE HELP ME TO FIND THE SOLUTION REGARDING "LOGICAL SYSTEM CHANGED" during the material master replication by using middleware parameters.
step1 : i have taken SRM client 810 and named it as CHINNISRM
step2 : i have taken r3 client 810 and named it as CHINNIR3
step3: During material master replication i maintained tables like crmconsum,crmrfcpar,crmparoltp in r3 and smofparsfa in srm client and filtered the objects and loaded the objects through r3ac3,r3ac1,r3as.
step4 : And later i have checked in r3 queues to activate the objects,but i have seen a message like "LOGICAL SYSTEM CHANGED:SEE 588701".according to the oss instructions i have checked in CRMPRLS table in se16 in R3 .there i found out there is one logical client named with T90CLNT810.
oss :588701
Solution
There are different cases in which different forms of processing are
required or where several options exist:
- The logical system name of an R/3 Backend client was changed in
current operation. In this case, the data hangs in the outbound
queues of the R/3 Backend system as specified under point 1 of
the symptom. In this case, the logical system name must be
changed back to the original value. Then the outbound queues
can be reactivated. If no data was transferred to the EBP/CRM
server before the change, also a correctioin of the check table
is possible.
- The same logical system name was used again in a new client of
an R/3 Backend system that was linked to the EBP/CRM server. In
this case, the data is in the inbound queue of the EBP/CRM
server with the exception GUID_FOR_LOGSYS_CHANGED. In this
case, the queue entries which have status SYSFAIL must be rejected, however, not the entire queues. If the new client of the R/3 Backend system you have linked has exactly the same
data as the old client and if it is meant to replace the old
client (that is, this was deactivated), also a correction of
the check tables is possible. In this case, the inbound queues
can be reactivated after the correction.
oss:765018
1. If the situation in your system corresponds to the situation described
under "Reason and Prerequisites" and if symptom 1 occurs, you can
delete the table entry from table CRMPRLS table (there is just one
entry). Since there is no maintenance dialog for this table and you
cannot maintain it using transaction SE16, you must use a report to
delete it. This report is attached to this note as correction
instructions.
Create the report ZZ_DELETE_CRMPRLS in your system and copy the source
code from the correction instructions. You cannot implement this
source code using transaction SNOTE.
You can use the report in every plug-in or plug-in basis system, even
if it is not specified in the validity section.
After you have run the report, you can trigger existing queues again
in transaction SMQ1.
2. If the situation in your system corresponds to the situation described
under "Reason and prerequisite" and if symptom 2 occurs, you can
delete the entry from table CRMMLSGUID (there is just one entry).
Since there is no maintenance entry for this table and you cannot
maintain it using transaction SE16, you must use a report to delete
it. This report is attached to this note as correction instructions.
If they do not yet exist, add the following messages to message class SMOF in your logon language:
Message Message short text
303 User &1 is not allowed to change table &2.
304 User &1 IS not allowed to display table &2.
305 Logical system &1 was not found in table &2.
306 System error! The current client was not
found in table T000.
Create the report ZZ_DELETE_CRMMLSGUID in your system and copy the
source code from the correction instructions. You cannot implement
this source code using transaction SNOTE.
You can use the report for every release of the CRM system, even if it
is not specified in the validity section. The only exceptions are CRM
releases with Support Package versions that are too low such as CRM
Release 3.0 with Support Package 12.
After you have run the report, you can trigger existing queues again
in transaction SMQ1 of the R/3 back-end system or transaction SMQ2 of
the CRM system.
so what should i do to do the replication.please suggest me .untill and unless i solve my problem i cant move to the further activity.i hope you people can solve my problem.thanks in advance.
thanks and best regards,
n.chakradhar

Hi chakradhar,
Did you find a solution to your issue? We are facing a similar issue and looking to figure out how this can be resolved.
BR// 420

BW / SolMan Logical System Change

Hello all, I am having a BW related issue and would really appreciate some advice. I realize some of this is for the solMan forums and will cross post (I normally dont)
ENVIRONMENT
New installation of Solution Manager EhP1 (19). System name is ED0. We are running Windows / MS SQL
System is only for Solution Manager ops (client 001), and CUA master (client 950).
BACKGROUND
We want to use full SolMan capabilities. This seems to include some limited BW interaction. We do not use BW in the landscape, so will rely on the "internal" BW in SolMan.
During installation, our person made a new client (000 > 400), set it as default (login/system_client), then ran tc:RSA1 and activated the content. (This sets the client)
Client 400 HAS NOT BEEN USED FOR ANYTHING other than the initial installation, and subsequent activation of BW. It has no connections to other systems, no data, cubes, or anything
PROBLEM
We were NOT AWARE that he had ran RSA1 and activated content, and began using client ED0_001 as our PRODUCTION SolMan client.
We are now unable to run RSA1 in anything but client 400.
We are unable to change the client 001 logical system name because Solution Manager has been built around it.
TROUBLESHOOTING
We changed table RSADMINA / field BWMANDT to 001 from 400. This changed the error from "You can only run in client 400" to "The logical system name has changed" (exit only)
In sandbox I duplicated this problem, then deleted the 400 client (with T000 entry). Changed the login/system_client to 001, RSDAMINA to 001, and ran function module RS_MANDT_UNIQUE_SET (set i_mandt to 001). After restart, RSA1 gives same error, logical system name changed"
On same sandbox after #2 above I attempted tc: BDLS to see if it would let me assign an exisiting logical system. It did not
QUESTIONS
Will it have any impact on Solution Manager operations to have the "BW Client" on ED0_400 while Solution Manager production is on ED0_001?
Is it possible to change the BW operating client to 001 from 400? (said another way, can I change the current logical systems BW is keyed with to a different, but existing, logical system)
Assuming the answer to Q1 is yes, and the answer to Q2 is no, what steps need to be performed to make BW fulfill the SolMan requirements?

Updated Information - Answer to Question #1.
I am embarrased I missed this section in the master guide the first time around. I will leave the question unanswered in case someone has an easy rememdy to changing the BI client logical system, as I would like to have it in my productive client if possible. However I am relieved I have the option of running it separately in case that can't be done.
There are three major options to consider when planning your system landscape in regards to BI.
BI in the Productive SAP Solution Manager Client
In this scenario, BI is used in the same productive client as SAP Solution Manager. This option allowsfor simpler configuration, and isolates the BI activities conducted for solution life cycle management from the data on a production BI instance. This is SAPu2019s recommendation.
BI in a Separate Client on SAP Solution Manager
In this scenario, BI activities are conducted in a separate client on the SAP Solution Manager system. This scenario provides increased security, as user access is more restricted. However, you must maintain users separately and this increased your administration effort. There is no technical benefit.
BI in a Separate, Non-Productive BI System
In this scenario, the BI activities are conducted in a separate, nonproductive BI system in the landscape. Data is sent to this system from the SAP Solution Manager system via RFC. This is only needed in rare cases for sizing purposes.

Master data in SRM when backend system change

Hi SRM Gurus,
Our scenario is ECC5 as backend system integrated with SRM 4.0( SSP scenario and iwith Catalog CCM2.0) Tech Implementation scenario is Extended classic .
Now our backend system will be changed to ECC6 from ECC 5.
ECC6 is installed on separate server for implementing changes in FI ( separate Dev, QA, Prod environment )
Question is that when we integrate SRM4.0 with ECC6, all master data (product categories, products & vendor master) needs to be replicated from ECC6 to SRM4.0
As SRM system will remain same what will happen to present master data in Production system.
As deletion is not suggested what is the correct approach.
We can delete this master data in SRM Dev and QA.
Can we keep master data pertaining to ECC5 as it is in SRM.
Any idea as to what type of impacts one can expect if backend system changed from ECC5 to ECC6? Is there a recommended approach for this?
I already referred note SAP note 418886 /995771.
Regards,
Avinash

Hi
By changing to ECC6.0 you would be entering a new backend system. Since the master data in SRM is linked to the respective backend system, it should not impact you.The old master data would still be there but linked to old backend system. You can let the data remain as it is if you want.
Regards
Sanjeev

Changing OPS$ passwd during system refresh

Hi All,
i have to do system Refresh/system copy ,i m using oracle 10g database.
while studying the docs and sap notes,i found that after database is backed from source system and restored in target system
.It is also required to change some passwords for OPS$ or SAP<Schema> user in table "sapuser" at OS level.
I am totally unaware of any such activity.can someone help me in this regard,as what are the post steps after DB is restored in target system and to how to perform them.
We are using brtools here.
Also what is the command line for restroring DB while system copy.
Regards,
Vishesh S

*Hi,*
*1.*
*can someone help me in this regard,as what are the post steps after DB is restored in target system and to how to perform them.*
After doing DB restore, one has to
a. Apply the Control files of source system database
b. Perform DB recovery by applying available offline redo log files (based on Complete DB recovery or Point-in-time DB recovery).
c. Then after successful DB recovery, one has to OPEN the database with RESETLOGS options.
d. Upon successful Database instance startup, Start Target SAP system
*2.*
*what is the command line for restroring DB while system copy.*
brrestore -b logfilename -m full
e.g. brrestore -b bcnmhluz.aft -m full
*3.*
a) Logon using the OPS$ user ("connect /@<sid>") to determine the
sapr3 password that is stored in the database table SAPUSER.
Now i have no idea,that how to check the password,as i logged in using "connect /",it just got connected.
But how will i know that what password has been set.
In OPS$ connection mechanism, only the existence of ops$<sid>adm user requires. Under <sid>adm OS user if you execute "connect /" in SQLPLUS, then it will get connected with Database through ops$<sid>adm database user, without asking for password.
During OPS$ connection mechanism, the SAP work processes get connected to Database using this OPS$ user. Then as a next step, the password of Schema user (SAPSR3 or SAP<SID>) is read from the SAPUSER table from database, and then with that password od schema owner , the R/3 work processes actually get connected with Database Instance schema. So the SAPSR3 password should be same at Oracle DDIC and SAPUSER table levels.
If you do not know the password of SAPSR3 or SAP<SID> database users, you can change them with br*tools or by the execution of the following brconnect command.
brconnect -f chpass -o [sapr3 | sap<sid> | sap<xyz> | sapsr3] -p <new_password>
(Refer SAP Notes 562863, 361641 as reference)
*4.*
*after doing a system copy/refresh, what changes i have to perform in OPS$ user.*
If your getting with OPS$ user issue while SAP startup or R3trans -d execution, then you can refer SAP note 40024 or do the following .
a.
Check weather the correct OPS$<SID>ADM user exists at DB level or not ?
SELECT * FROM DBA_USERS;
b. If the required OPS$ user does not exist in Target DB....
CREATE USER "OPS$<SID>ADM" DEFAULT TABLESPACE <user_tsp> TEMPORARY TABLESPACE PSAPTEMP IDENTIFIED EXTERNALLY;
c. Grant roles/previleges to OPS$ user
grant sapdba to ops$<SID>ADM;
d. check the existence of SAPUSER table and the owner of SAPUSER table in target DB
SELECT OWNER FROM DBA_TABLES WHERE TABLE_NAME = 'SAPUSER';
e. If the owner of SAPUSER table is not OPS$<SID>ADM, then u need to drop it and recreate it in Database.
-- DROP TABLE "<owner>".SAPUSER;
-- CREATE TABLE "OPS$<SID>ADM".SAPUSER (USERID VARCHAR2(256), PASSWD VARCHAR2(256));
--INSERT INTO "OPS$<sid>ADM".SAPUSER VALUES ('<sapowner>', '<password>');
f.
Execute R3trans -d under <sid>adm OS level user and verify its return code. Also check trans.log file
5.
what is the middle step between db recovery and starting the system.
middle steps can be
a. to OPEN Database with RESETLOGS or NORESETLOGS option and restart the DB instance.
b. create OPS$ Database user according to new SID and new <SID>ADM OS user
I hope the above information will be helpful to provide you possible understanding.
Regards,
Bhavik G. Shroff

SE03 / SE06 System Change Option Scope

Hi All,
We are creating a source system from R/3 to BW in some specify step we need to change the System Change Option of the sistem in a particular client (SE06 -> System Change Option -> No Modifiable to Modifiable and Modifiable to No Modifiable).
My question is: This changes are Cross Client?
Or only apply to the specify client where you are logged?
Best Regards,
Erick Ilarraza

On their own, Global and Compenent specific change options are not client dependent as they are not related to the logical system of the ABAP user nor the master and transaction data (tables with field MANDT as key).
Personally, I think of it as a "call stack" of checks on whether and what you can modify. Perhaps "System Change Update-ability" would have been a better label, but that is not good English.
As the stack is released for a user in a client (a logical program system), the system determines what can be updated at different levels of the stack as it unfolds, a bit like a spring. At the top there is SE06. At the bottom of the spring there are individual authority-checks which are system, client, program flow and context, and user access dependent.
Depending on where in the stack you release the spring from and how you got there, your user can update parts of the stack. Often the term "logical systems" is used in connection with the client (SCC4 client), but also many others such as workflow etc.
=> If the user can pass authority-checks for access at the bottom of the stack (S_DEVELOP is the key control here), then they can also change that which the top of the stack was designed to control. If you can debug, then there is nothing which will stand in your way.
> My question is: This changes are Cross Client?
It depends. You still need to control access via authorizations within the client to secure access to the whole system.
Cheers,
Julius

Error "Choose a change request with target system..."

Hi experts,
I am trying to change an infosource and keep getting this error "Choose a change request with target system BWQ"
How do I correct this?
Thanks!

Hi,
Check out source system Id's are properly assigned or not.
go to tools ( CtrlShiftF11)
assign point if it helps
Regards,
sandeep

What should BASIS do for an InfoSource transport for Souce System change?

We just create a change request for an InfoSouce. Now we transport this change request from DEV system to TEST system. But when this change request was imported on TEST system, got the "Method Execution" red error which can be checked through STMS in log. The red error msg is "Source system A does not exist", where A is our R3 DEV server. Actually we need the source system B which is R3 TEST server in the InfoSouce transported into BW TEST system, but the problem is that the change request was created on BW DEV which uses A as Souce System in the InfoSouce, then how to make the InfoSouce has B on BW TEST after the transport?
Thanks

hey Roberto,
I think this setting should be conducted on DEV system other than the target TEST system as you said, am I right. Since we conduct the transport on DEV through the Transport Connection and the settings of the mapping of the source system should be set on DEV, right?
Our BASIS know nothing about BW that we can't depend on them even if this is BASIS work.
Thanks

Source system changes impact on BI system

Similar Messages

Maybe you are looking for