Best Practice to transport MDM Workflows trough a 3-tier Landscape

Hello Experts,
I wanted to ask you for some Best practices to transport MDM Workflows from D-to Q/P?
Well besides the Archive/Unarchive method because we want to keep the Data of P in the repository
and do not want to import the whole.
Any ideas? Points are for sure!!
Best regards
Carsten

Hi Carsten,
Currently with the MDM 5.5 version the only transport mechanism that will allow you to export your Workflows from the development server to the Production or Quality is the Archieve/Unarchieve method.
but this methods archives the data as well along with the workflow.There is no such method to exort the workflow alone.
But with the onset of the MDM 7.1 there are new transport mechanism included and hopefully they address this issue.
A work around that i can think of at this moment:
- If you have your development server as your Master rep and the Production server as your slave
- Then you can call the workflow from the D to the P.If you do not have any data presntly in the dev.
- and then Normalize the Productions server to make it an individual master rep with its own data.
I am not sure how well this solution will help but just a suggestion....
Hope It Helped
Thanks & Regards
Simona Pinto

Similar Messages

Best practices for transport of setup of archivelink/contentserver

Hi
I'm using the archivelink setup to store all kind of documents/files and to archive outgoing documents and print lists (print and archive).
But I don't know how we should transport the setting.
We need different setup in dev/qa/prd systems because we don't want documents from our development system stored in the same server as the documents from our productive system.
We have 2 setup used in different scenarios :
1) We link the ObjectType/Doc.type to different content repositories in OAC3 (D1 for dev, Q1 for qa and P1 for prd)
2) We point the content repository to different HTTP servers in OAC0/CSADMIN
In both scenarios I see 2 options.
1) open for customizing in qa and prd systems and maintain the different setups directly in each system.
2) We Transport the prd content repositories all the way, but delete the transport with qa content repositories after import to the qa system and finally we don't transport the dev content repositories at all.
Both options are bad practices, but what are Best practices?
Best regards
Thomas Madsen Nielsen

Hi David,
The best mechanism is probably transporting the objects in the same order as creating/changing them. The order would be Application Components, Info Area, Info-objects, Transfer Structure, Transfer Rules, Communication Structure, InfoCube, Update rules, Infopackages and the frontend components.
There are many topics on BW transports in SDN forum. You can search for them.
You can refer to this link for more details on transports in BW System:
http://help.sap.com/saphelp_nw04/helpdata/en/b5/1d733b73a8f706e10000000a11402f/frameset.htm
Bye
Dinesh

Best Practice: Migrating transports to Prod (system down etc.)

Hi all
This is more of a process and governance question as opposed to a ChaRM question.
We use ChaRM to migrate transports to Production systems. For example, we have a Minor BAU Release (every 2 weeks), a Minor Initiative Release (every 4 weeks) and a Major Release (every 3 months).
We realise that some of the major releases may require SAP to be taken offline. But what is SAP Best practice for ANY release into Production? i.e. for our Minor BAU Release we never shut down any Production systems, never stop batch jobs, never lock users etc.
What does SAP recommend when migrating transports to Prod?
Thanks
Shaun

Have you checked out the "Two Value Releases Per Year" whitepaper for SAP recommendations? Section 6 is applicable.
Lifetime Support by SAP &raquo; Two Value Releases per Year
The "real-world" answer is going to depend on how risk-adverse versus downtime adverse your company is. I think most companies would choose to keep the systems running except when SAP forces an outage or there is a real risk of data corruption (some data conversions and data loads, for example).
Specific to your minor BAU releases, it may be wise to make a process whereby anything that requires a production shutdown, stopped batch jobs, locked users, etc. needs to be in a different release type. But if you don't have the kind of control, your process will need to allow for these things to happen with those releases.
Also, with regards to stopping batch jobs in the real world, you always need to balance the desire to take full advantage of the available systems versus the pain of managing the variations. If your batch schedule is full, how are you going to make sure the critical jobs complete on time when you do need to take the system down? If it isn't full, why do you need that time? Can you make sure only non-critical batch jobs run during those times? Do you have a good method of implementing an alternate batch schedule when need be?

Transport Best Practices - Cumulative Transports

Hi All,
    I am looking for a some sort of authoritative guide from SAP on ECC Transport Best Practices, especially around merging/combining/accumulating multiple transports into fewer ones. We are a very large project, but we haven't figured out the CVSs like ChaRm so we still deal with individual transports.
The reason I am asking this is that we some development leads on our project that insist that ALL transports that leave Development system must be imported into Production. They claim this the SAP best practice. An SAP consulting review of our system also left a vague note that "We are orphaning transports". This could mean that 1. either we are not importing all the stuff that leaves Dev system 2. or we are not keeping track of our code changes across all environments. Proponents of "All transports must get to PRD" are interpreting this as "1".
I have my team cumulate transport for subsequent changes into newer transport and only take the newest Transport to Production. The continuous rolling of old Transport into new one using SE01 "Include Objects" options ensures that all changes part of current development are in a single TR. Fewer transports mean fewer housekeeping across all systems, and less chances of something going out of sequence or missed out. This is for Workbench Transports only. I understand Config transports could get a little tricky with rolling in.
If you can't point me to a link, what is your take on "Send everything to Prod" vs. "Combine changes into fewer Transports"? I can't think of any software packaging methodology that suggests putting everything, including some junk/crap, into production build. I have looked at SAP enhancement packs, SPS, and Notes. I haven't found any evidence of SAP including older buggy code in what it releases to its customers.
Thank you all!

Jānis, Christian,
    I think we are all on the same page. Let me clarify my specific scenario a little bit more.
We are about 15 ABAP developers team, for production support. We don't do huge changes. Our code updates are mostly limited to a handful of objects (average 2 - 5). We often have multiple iterations to same objects. For large scale development objects, this approach may not work very well. Those should really utilize SolMan or other CVS tools.
Here is How I have my team putting together final transport.
step 1. Change is done to object X. Transport #1 created and released after standard checks.
step 2. More change is needed for object X. Transport #2 Started. Transport #1 is brought in using SE01 include objects at the main task. Changed objects are in lower tasks. This way, I can tell what was brought over, and what really changed this time. Releases of the Transport #2 inspects all objects and insures all objects from #1 are included in #2, and that there are no other changes between #1 and #2 to any of the objects. This is very easy check mostly from Version History.
Step 3. More changes needed to object X and Y. Transport #3 started. Transport #2 brought in at main task. Same check from Step 2 is done to ensure no other changes exist.
step 4....6. Step 6 ended at Transport #6. All changes verified in QA system.
Only the Transport #6 needs to be sent to Production since previous Transports 1 to 5 were rolled into #6.
Jānis, the deletions will be covered automatically just like standard SAP. No special manual steps needed.
Christian,
   The transport of copies works in similar way. Only thing different is that the Main/cumulative transport is released at very last, possibly after QA tests have been confirmed.
I had thought about doing Copies vs. cumulative. I preferred to go with having Transport in QA already at the time of approval. I would have hard time explaining to our client why a Transport was released out of Dev After all tests were done and signed off.
However, the Copies have advantage that intermediate versions or parallel changes of same objects are easily recognized upfront vs. us having to check each transport before release.
Jānis, the "copies of Transport" also creates extra versions in version history just like manually adding objects in a transport.
My quick analysis between copies and cumulative only came with one different that 'copies' have a different flag/attribute in Table E070. I am sure the flag means something to SAP, but for versioning history, it makes no differences.
Regardless of if I cumulate or not, based on your experiences, have you come across notion that everything that leaves Dev must get to PRD as SAP Best Practice? What would your reply be if someone insists that is the only way to move code to production?

Best practice to transport KANK parameters?

Hi all,
My point is about Number ranges for CO document.
SAP help indicates (for KANK transaction - number ranges for CO document) that i is preferable not to transport the number ranges parameters from the source environment to the cible. I guess the reason is that it is to guarantee the coherence between the source and the cible.
My situation is the following: my environnements are new, so I am initializing the CO environment. I am starting from scratch! By the way, I think that I could easily transport KANK parameters without any discordance problem, because there are no postings in the cible.
My question is: what do you think of my transport procedure? The point is that I will need to follow the same transport procedure for all the environments in the future.
Cheers
Pascal

I don't agree.
For an initial system build it is probably preferable to transport number ranges so that they are done consistently. You know... we all make mistakes and if you have to manually replicate this for every sytem build (Test, QA, Training, Production, Production Fail, etc.) even the best of us will make a mistake.
I wouldn't transport in a live system for the very reason that the system issues the warning when you save the changes. But for a new build I would do it.
Just my opinion...
-nathan

Best Practice transport procedure for SRM-MDM Catalogue repositories change

Hi,
I have a question regarding SRM-MDM Catalogue repository change transports.
We currently have two QA servers and to Production servers (main and fail-over).
We are investigating the need of a Development server.
Changes are being made to the repositories on the system, and I see the need of a dev server.
What is best practice for SRM-MDM Catalogue?
With only QA and Prod environments I guess Repository schema transport is the best option, since there has not been created a Refference file (which is needed for change file transport).
Any other options?
We are running MDM as well, with dev, QA and prod environments. Here we use CTS+ for transports.
Is it best practice to use CTS+ also for SRM-MDM Catalogue transports?
KR,
Thomas

Hi Thomas.
What is best practice for SRM-MDM Catalogue?
SAP recommends to have the landscape model like DEV-QA-PROD.
So in case of catalog as well if we follow the same technique it will help you to have a successful implementation
Any other options?
As a part of proceeding with the CTS+ you need to create a reference file
Refer the Link: [CTS+|http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d0dd1ae0-36e5-2b10-f8b4-e6365e643c0b?quicklink=index&overridelayout=true] for more details
Is it best practice to use CTS+ also for SRM-MDM Catalogue transports?
It is upto the requirement. if you feel there are many changes in catalog xml schema in various phases in an automatic manner then you can go ahead with CTS+ or you can perform the existing method of exporting and importing the schema to the repository.
Hope it helps.
Best Regards
Bala
Edited by: chandar_sap on Sep 28, 2011 12:17 PM

Best Practices For Portal Content Objects Transport System

Hi All,
I am going to make some documentation on Transport Sytem for Portal content objects in Best Practices.
Please help in out and send me some documents related to SAP Best Practices for transport for Portal Content Objects.
Thanks,
Iqbal Ahmad
Edited by: Iqbal Ahmad on Sep 15, 2008 6:31 PM

Hi Iqbal,
Hope you are doing good
Well, have a look at these links.
http://help.sap.com/saphelp_nw04/helpdata/en/91/4931eca9ef05449bfe272289d20b37/frameset.htm
This document, gives a detailed description.
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f570c7ee-0901-0010-269b-f743aefad0db
Hope this helps.
Cheers,
Sandeep Tudumu

Best practices to manage Materials+Vendors in an SRM-MDM Respository?

Hi Gurus,
I have a functional question about how manage the Master Data of "Materials" and "Vendors" in an scenario of SRM-MDM Catalog (Repository). MDM 7.1, SRM 7.0, MDM-SRM Catalog (Repository) 7.0.
My concern is that this kind of repository has 32 fields aprox. and the majory of fields are referenced to Material information and a little fields of Vendors.
The big question is how load or modeling the information in the Repository?
Which are the best practices?:
a) Manage the materials in the main table of the repository and then add other main table to maintain the vendor data?
b) Manage the materials and the vendors in different repositorys?
c) Manage the materials & vendors in the same main table in one repository?
I know that part of the solution depends of the SRM Team requiriments, but I would like to know what are the best practices from the MDM Side.
Thanks in advanced.
JP

Hey JP,
Couple of questions to you.
Do you have Material and Vendor Master in SRM or ECC or BOTH ??
What will be the scenario, Consolidation, Catalogue Management or CMDM??
What will be POC for Mater data?
Cheers,
Rajesh

Best Practice for unimplemented OTC project transports?

Hello,
We implemented and went live with portions of ERP modules COPA, MM, GL(new), and Consolidations 2 years ago as a Phase 1 implementation. Phase 2, which began directly afterwards, included CRM, OTC, and BW. The problem that has come up is that due to numerous implementation issues, we have not gone live with Phase 2 and it is still undetermined when/if we will implement at least OTC in ERP. We have a 3-system (Dev, QA, Prod) ERP landscape and are running into issues due to inconsistencies between QA and Prod. All the transports related to the Phase 2 project were created in Dev and moved into QA, but due to the status of the project were never moved into Production. We recently had an issue with moving changes to our operating concern through the landscape, due to the existing inconsistencies of the operating concern configurations between Dev, QA, and Prod which led to us not being able to re-activate the Operating Concern in Prod until we moved in additional transports that were tied to Phase 2.
My question is this...What would be the best practice/approach to resolving the inconsistencies in our ERP landscape to assure that we have accurate QA testing of our Phase 1 implementation, but also trying not to lose the existing Phase 2 development if we decide to implement OTC in the future? I'm considering the below options:
A) Move all Phase 2 requests
- Refresh QA (via system copy of Prod)
- Move all Phase 2 transports that were originally moved into QA into the refreshed system and test existing Phase 1 business processes to determine risk of moving into Prod
- Move all Phase 2 transports into Prod in order to maintain 3-system consistency
B) 2 system consistency
- Refresh QA (via system copy of Prod)
- Leave all Phase 2 transports in import queue for QA, and maintain Prod/QA consistency only
- OTC implementation can be realized with moving Phase 2 transports through QA at some point in the future
C) "Reset button"
- Refresh QA (via system copy of Prod)
- Refresh Dev (via system copy of Prod) - I'm not sure what technical considerations would need to be made around the development system's role as the origin of rep and dictionary objects and how this can be maintain in a system copy?
- This would wipe out all Phase 2 development
I would greatly appreciate anyone's guidance on our options given our current scenario.
thanks,
John

I would suggest to go with the option A though it seems more work with this option. But this is the only option which can effectively work in the long run. With option B, you will not completely eliminate the problem and with option C, you will loose all your phase 2 work, which will be big waste of the efforts.
Additional advantage with option A is that whenever your organization decides to go-live with Phase 2 work then minimal regression testing will be required as most of your work will be already tested and verified. Regression testing and remediation is significant work whevever a solution is introduced in a working environment.

MDM workflow transfer from repository to repository

How to transport mdm workflows (as records & visio content) from one repository to another repository.
We just need workflows information from one repository to another.

Hi Ramu,
This link is very useful as it guides for the best practises involved while transporting MDM repositories and its objects. It also tells the limitation of the present version in transporting some certain objects.
How to Transport Master Data Management Objects between Master Data Management 5.5 Systems (NW7.0)
https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/20751e78-f81f-2a10-228f-eb3a16421b4d
You can either Archive in your case from the source repository and then Un-archive it in the target repository ( this too will copy everything) or else you can simply duplicate the rep. This will create a copy of the source and then manually you will have to delete all the un-wanted things.
If both these approach doesnt suit in your requirement, then I am afraid you will have to create the workflows manually in the target repository. Transportation of MDM objects is still not very strong enough in current versions. However, we can expext more improvements in the upcoming versions.
Hope it helps.
Thanks and Regards
Nitin Jain

Creating Billing Unit in CRM V1.2007 Best Practices C05

Hi,
in C05 (Org Model with HR Integration) for Best Practices V1.2007 I have to create a Billing Unit.
That means, I have to create a Corporate Account.
For Creation of the Corporate Account i need a Number Range and a Grouping.
My Question:
Maintaining Number Range and Grouping for Business Partners is described in C03.
In the Solution Builder C03 comes after C05.
So I have first to finish C03 manually via SPRO or at least I have to maintain a Number Range and a Grouping so that I´m able to create the Billing Unit as an Corporate Account and then proceed with C05?
Regards
Andreas

Hi Padma,
We are facing the same issue while installing Baseline Best practices.
"Transport numbers not fullfill the requirement"
We are trying to activate full solution.
I have already created a new work bench and customize request ,but stills its gvg "Transport numbers not fullfill the requirement".
Iam not able to find a solution for this on service market place.
Thanks & Regards,

Best Practice/Standard for Securing and Attaching Files in a Web Service

Thanks in advance.
Being new to Web Services as well as most of my team. I would like to know what is the best practice for transporting files via a Web Service. I know of several methods and one that seems to be the standard, but you can't really tell in this ever changing world of Web Services. Below are the options that I have found.
1. MIME encoded the file and embed in the payload of the SOAP message
2. SwA (SOAP with Attachments) which applies MIME attachments to SOAP. I think this is similiar to the way emails are handled.
3. DIME (Direct Internet Message Encapsulation) similiar to MIME encoding but is more efficient
4. MTOM (Message Transmission Optimization Mechanism) I really not understand this method, but it seems that this is the NEW standard. I just don't understand why.
5. Utilize HTTPS and download the file from an accessible file server w/ a login id and password.
Is there someone out there that understands this problem and can assist me in understanding the pros and cons of these methods? Or maybe there is a method that I'm overlooking altogether.
Thanks

JWSDP supports securing of attachments [1]and will soon support securing MTOM attachments too. [1]http://java.sun.com/webservices/docs/2.0/xws-security/ReleaseNotes.html

Best practice approach for seperating Database and SAP servers

Hi,
I am looking for a best practice approach/strategy for setting up a distributed SAP landscape i.e separating the database and sap servers. If anyone has some strategies to share.
Thanks very much

I can imagine the most easiest way:
Install a dialog instance on a new server and make sure it can connect nicely to the database. Then shut down the CI on the database server, copy the profiles (and adapt them) and start your CI on the new server. If that doesn't work at the first time you can always restart the CI on the database server again.
Markus

Web Intelligence Security Best Practices

Hi All,
We are in the process of starting to use web intelligence. I am puttng together a security model for it and I have some questions around best practices. We have a fairly simple two tier security model so far, end users and creators. Creators will be able to create reports in certain folders and everyone else will be able to run and refresh those reports they can see.
I was going to create a group for all the creators and assign them to a custom access level in the web intelligence application. Then they would also need to be in another creator group for the particular folder. So they would be able to the create reports in that folder and execute reports in another.
For all the end users, they need to be able to view and refresh reports, drilling, data tracking, etc. if they have access to them. Is the best practice then to just assign the Everyone group the out of the box view on demand access level?
I have been digging around looking for resources and welcome anyone's input or ideas on the subject.
Thanks in advance for any assistance provided.

Thank you for your prompt reply.
But that means that the same security groups will need to be creaed on both palces, web intelligence application and at the folder level?
I was thinking if I create a developer group for the web intelligence application level, all developers would go into there. Then at the folder level I could create another folder level security group for developers to access the folder.
Would that not simplify the maintenance at the application level? Or would that not work?

Export and Deployment - Best Practices for RAR and CUP

Hi Experts,
I wanted to know what in your opinon is best practice for deployment for GRC for a 3 system landscape.
We have a development landscape which connacts to all our environments - Dev-QA-Prod.
Is it recommended to have just the production client connected to the prodiction boxes only and use Dev/ QA for other environments or is it a good idea to have Prod and QA in sync?
In my opinion it looks like a good idea to have the same QA and PROD as it would make export easier.. Maybe I am worng..
What according to you all is a good recommended practice here?
Thanks,
Chinmaya

Hi Chinmaya,
depends how many clusters you have in your landscape
if it is something like 5 DEV box to connect 5 QAS boxes, so on
then best practice will be to have separate DEV - QAS - PRD boxes for GRC if money (h/w ) is no constraint for organization
rather than later asking SAP for deletion scripts for deleting sandbox or dev connectors,
best to have separate boxes for each
also for future whenever you do rule changes in RAR and config changes in CUP, best to test in QAS first, as CUP will become very critical for your organization, post go-live
and good part will be that management report will reflect true data for PRD only
regards,
Surpreet

Best Practice to transport MDM Workflows trough a 3-tier Landscape

Similar Messages

Maybe you are looking for