cancel
Showing results for 
Search instead for 
Did you mean: 

Portal usages types installed in SAP ERP60

Former Member
0 Kudos

Dear SAP gurus,

I found out that my customer's ERP environment has the following systems:

-Development with ERP and Portal usage types installed

-Quality with ERP and Portal usage types installed

-Production with ERP usage types installed

Therefore, they have "Portal usage types" installed in Development and Quality that are not used/need (they already have SAP Portal with those usage types in different servers).

The request is to provide them the best strategy to maintain (patch, upgrade, etc) their ERP systems.

I can think about 3 possible solutions here:

1.-Do not touch the three ERP systems (dev,qas,prd) and install another system (sbx, as a copy of production) to be able to patch before doing it in production. I dont like it bc (dev and qas)'s components will likely have different versions than (prd,sbx)'s components.

2.-Install also the Portal usage types in Production. I dont like this solution because Im installing sw that im not going to use in a productive system...

3.-Install Deveopment and Quality systems from scratch, then perform a system copy from the productive system, perform the client copies from old dev and qas systems and finally setup all connections to PI, Portal, Solman, etc...

Can you guys please give me your opinion/suggestion on what would be the best approach to "clean" the ECC environment?Initially I would go for solution 3 as the ECC landscape will be synchronized and we won't need to touch a productive system but I am not sure due to the high complexity?!

It would be great to see your opinions about the 3 possible solutions or if anyone comes up with a new one.

Thanks in advance, Marc

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Marc,

Please find my opinion on these 3 options below:

1.-Do not touch the three ERP systems (dev,qas,prd) and install another system (sbx, as a copy of production) to be able to patch before doing it in production. I dont like it bc (dev and qas)'s components will likely have different versions than (prd,sbx)'s components.

All system in the landscape should be on same patch level and they should have same components.So leaving Production system different to Dev and QA is not ideal scenario.

2.-Install also the Portal usage types in Production. I dont like this solution because Im installing sw that im not going to use in a productive system...

I would go for this option.Installing Portal Usage type,with will just include EP-Core and EP.Very straight forward and clean approach.

3.-Install Deveopment and Quality systems from scratch, then perform a system copy from the productive system, perform the client copies from old dev and qas systems and finally setup all connections to PI, Portal, Solman, etc...

Not recommended to build Dev system from scratch.

Regards,

Ashuotsh

Former Member
0 Kudos

Hi Ashuotsh,

First of all thanks a lot for your answer.

1. Agreed.

2. Dont you agree that the more software the more problems?I am a little bit reticent about installing no need it software on a productive system.

3.Why is not recommended to install a new Development system from scratch?Is it because of the complexity?

Regards, Marc

pd. Anyone has more suggestions?

Former Member
0 Kudos

HI,

Just adding my more on my point of view on this:

2. Dont you agree that the more software the more problems?I am a little bit reticent about installing no need it software on a productive system.

EP-Core and EP components,which forms base for Portal usage type will not cause any harm in your system,performance wise.So,i dont see any risk in this option.This will be my safest bet.And may be in future you will have to use them.

3.Why is not recommended to install a new Development system from scratch?Is it because of the complexity?

I believe risk is involved in rebuilding Dev system if not carried out correctly.Which method you are going to use?

Export/Import will again bring all usage types and install from scratch will cause data /development work loss.

May be you can try DB copy method, and reinstall J2EE stack.

Regards,

Ashutosh

Former Member
0 Kudos

Hi Ashutosh.

2. The thing is that we already have a portal in a different server so there's no need of portal usage types in the ERP system.

3.The idea would be proceed with the following steps:

-Install the system from scratch.

-System copy using "DB and Central Instance Export" from Production system.

-Client copies from the old Development system of the clients which did not have the Production system.

If everything is done right I dont see why can be data loss...

Thanks and regards, Marc

Former Member
0 Kudos

Marc,

2. The thing is that we already have a portal in a different server so there's no need of portal usage types in the ERP system.

If there is no need on Portal in ERP which is in Dev and QA also, you can just shutdown the Java Instance rite or uninstall the Java from Dev and QA.

3.The idea would be proceed with the following steps:

-Install the system from scratch.

-System copy using "DB and Central Instance Export" from Production system.

-Client copies from the old Development system of the clients which did not have the Production system.

If everything is done right I dont see why can be data loss...

Here are the problems

1). You might loose your Transport sequence (atleast You can get that from E070 table) but chances of repeating transport numbers are more.

2). Client copies bring the Customization data but not WorkBench . So you might have to do transport of copies from Old Dev to New Dev.

3). If you do system copy from Production and do client copy from dev...obviously Prod customization will be overwritten with Dev rite ?

Thanks,

Arjun

Former Member
0 Kudos

Thanks Arjun,

>If there is no need on Portal in ERP which is in Dev and QA also, you can just shutdown the Java Instance rite or uninstall the >Java from Dev and QA.

We use ERP's Java stack for Adobe documents so I cannot shut it down.

>Here are the problems

>1). You might loose your Transport sequence (atleast You can get that from E070 table) but chances of repeating transport >numbers are more.

I didnt think about this. I see we will need to pay attention to increase the transport numbers before the new system is up and running.

>2). Client copies bring the Customization data but not WorkBench . So you might have to do transport of copies from Old Dev to >New Dev.

So you are saying that the system copy from Production will not bring Workbench data and I need to bring Workbench data by transports?

3). If you do system copy from Production and do client copy from dev...obviously Prod customization will be overwritten with Dev rite ?

That's what I expect to happen.

Regards, Marc

Former Member
0 Kudos

2). Client copies bring the Customization data but not WorkBench . So you might have to do transport of copies from Old Dev to >New Dev.

So you are saying that the system copy from Production will not bring Workbench data and I need to bring Workbench data by transports?

*system copy from Production will bring Workbench data also, but when you do client copy from development system again on top of client which already has production customization, data and workbench requests, Production customization and data will be overwritten from development customization and data (it depends on the profile you choose for the client copy) *

However Development Workbench requests are more and also has ongoing development work which might not be available in production client and those (Ongoing development workbench requests) you need to import in new system as transport of copies after the client copy

3). If you do system copy from Production and do client copy from dev...obviously Prod customization will be overwritten with Dev rite ?

That's what I expect to happen,

Ok, however, You might need to get Development Work too from the old dev system and don't forget about setting up of partner profiles in WE20.

It's just a thought , Do you have testing client in Dev, if not,You can leave the production client in development system and use it as testing client.

Create new client which is client copy of Old Dev and import WorkBench requests *

Thanks,

Arjun

Former Member
0 Kudos

Thanks Arjun for your comments and suggestions. I will take them into account.

Regards, Marc

Former Member
0 Kudos

Dear all,

SAP Support just got back to me and mentioned that it is possible to undeploy those java sw components on Development and Quality system so the Portal usage type will be removed. This could be done using SDM tool. Are you guys familiar with this?I thought that once you install a sw component, this cannot be uninstalled.

Best Regards, Marc

JPReyes
Active Contributor
0 Kudos

The details of how to undeploy are available in Help.sap.com

Regards

Juan

Answers (1)

Answers (1)

Former Member
0 Kudos

Hello Marc,

Are your Dev and Qua systems actively being used by customer for regular development and testing? If not, then I would suggest you to go for option 3.

If yes, I suggest you the following.

1. Install a new system with ERP components

2. Configure TMS and include this system into DEV/QUA transport domain.

3. Keep all your development and necessary objects into a transport request and release it from existing DEV system.

4. Import the transport request into new system. Then your new system will become like a DEV system with all development objects and ERP components.

5. Once you validate your new system, you can build new DEV system using system copy with above said newly built system.

6. Once your DEV system is ready, you can build QUA system using above steps.

Hope it helps. Please let us know if you nee any clarification.

Thanks,

Siva Kumar

Former Member
0 Kudos

Thanks for your suggestions Siva.

Yes, Dev and Qas are actively used for regular development and testing.

>1. Install a new system with ERP components

I understand that some steps need to be done between 1. and 2.

1.1.Patch the new system up to the same sw component level of DEV system. How do you think would be the easiest way to patch this?Perhaps performing a system copy (Database export-import) from prod?

1.2.Create the same clients in the new system as DEV system.

>2. Configure TMS and include this system into DEV/QUA transport domain.

This means to locate the new system in parallel to QUA so all DEV clients point to new system's clients?

Regards, Marc