Best Practices for APO Production Support

What are the best practices needs to be adopt for APO Production Support? in DP, SNP, PP/DS, CIF, APO-basis, APO -ABAP area?

I know this is not the standard way to reach you, but you answered a question long back about /SAPAPO/AMON1 - Alert Monitor. Can this alert monitor be configured to show up in the universal worklist (UWL) in the portal? if so would these alerts show up in the alert inbox of the uwl just as other sap alerts do? (the other alerts i speak of are those referenced here (http://help.sap.com/saphelp_nw04s/helpdata/en/3f/81023cfa699508e10000000a11402f/frameset.htm).
Or are these alerts two totally different types of functionality with the same name (ARERT) ?
Thanks
Ted Smith

Similar Messages

Best practices for development / production environments

Our current scenario:
We have one production database server containing the APEX development install, plus all production data.
We have one development server that is cloned nightly (via RMAN duplicate) from production. It therefore also contains a full APEX development environment, and all our production data, albeit 1 day old.
Our desired scenario:
We want to convert the production database to a runtime only environment.
We want to be able to develop in the test environment, but since this is an RMAN duplicated database, every night the runtime APEX will overlay it, and the production versions of the apps will overlay. However, we still want to have up to date data against which to develop.
Questions: What is best practice for this sort of thing? We've considered a couple options:
1.) Find a way to clone the database (RMAN or something else), that will leave the existing APEX environment intact? If such is doable, we can modify our nightly refresh procedure to refresh the data, but not APEX.
2.) Move apex (in both prod and dev environments) to a separate database containing only APEX, and use DBLINKS to point to the data in both cases. The nightly refresh would only refresh the data and the APEX database would be unaffected. This would require rewriting all apps to use DBLINKS though, as well as requiring a change to the code when moving to production (i.e. modify the DBLINK to the production value)
3.) Require the developers to export their apps when done for the day, and reimport the following morning. This would leave the RMAN duplication process unchanged, and would add a manual step which the developers loath.
We basically have two mutually exclusive requirements - refresh the database nightly for the sake of fresh data, but don't refresh the database ever for the sake of the APEX environment.
Again, any suggestions on best practices would be helpful.
Thanks,
Bill Johnson

Bill,
To clarify, you do have the ability to export/import, happily, at the application level. The issue is that if you have an application that consist of more than a couple of pages, you will find yourself in a situation where changes to page 3 are tested and ready but, changes to pages 2, 5 and 6 are still in various stages of development. You will need to get the change for page 5 in to resolve a critical production issue. How do you do this without sending pages 2, 5 and 6 in their current state if you have to move the application all at once??? The issue is that you absolutely are going to need to version control at the page level, not at the application level.
Moreover, the only supported way of exporting items is via the GUI. While practically everyone doing serious APEX development has gone on to either PL/SQL or Utility hacks, Oracle still will not release a supported method for doing this. I have no idea why this would be...maybe one of the developers would care to comment on the matter. Obviously, if you want to automate, you will have to accept this caveat.
As to which version of the backend source control tool you use, the short answer is that it really doesn't matter. As far as the VC system is concerned, you APEX exports are simply files. Some versioning systems allow promotion of code through various SDLC stages. I am not sure about GIT in particular but, if it doesn't support this directly, you could always mimic the behavior with multiple repositories. Taht is, create a development repository into which you automatically update via exports every night. Whenever particular changes are promoted to production, you can at that time export form the development repository and into the production. You could, of course, create as many of these "stops" as necessary to mirror your shop's SDLC stages, e.g. dev, qa, intergation, staging, production etc.
-Joe
Edited by: Joe Upshaw on Feb 5, 2013 10:31 AM

What is the best practice for APO - Demand planning implementation

Hi,
M client wants to implement demand planning.
Cient has come up with one scenario like a New Customer is created in ECC, and if I use BI and then APO flow for Demand planning, user will have to wait for another day. (AS BI is always having one day delay).
For this scenarios user is insisting on ECC and APO-DP interface.
Will anybody suggest what should be the best practice for Demand planning.
ECC -> Standalone BI -> Planning area (Planning is done in APO) -> Stand alone BI
Or ECC -> APO-DP (Planning is done in APO) -> Standalone BI system
I hope I am able to explain my scenario.
Regards,
Saurabh

Any suggestions !!

Best practice for adding products in multiple languages

We have multiple products with the same product number and product name - but have different descriptions (translations).
Our BigMachines quotation system allows us to have several language layers for the same product. But it seems like this is not possible in CRMOD?
I guess the work around would be to have x amount of fields containing the description in different languages in CRMOD.
Just wanted to confirm this before moving on down that road..
Regards,
Allan

Thank's Bobb. That was unfortunately the answer I expected.
I can't really wait for the enhancement, so I thought of the following work around:
- Rename the product name field to product number
- Create x amout of new product name and product description fields (for each language)
Do you see any pitfalls here?
Regards,
Allan

Best practices for Test - Production promotions

Good Day to all
Environment:
OWB Client: 10.1.0.2.0 on Windows XP Professional
OWB Server Side: 10.1.0.2.0 on UNIX (AIX 5.2)
Repository: Oracle 9.2.0.4 on UNIX (AIX 5.2)
Runtime Schema: Oracle 9.2.0.4 on UNIX (AIX 5.2)
I am trying to put together an idiot-proof process to have our Infrastructure Team (Operators) facilitate the promotion of OWB objects from our Test environment to our Production environment.
The Production environment is a separate OWB Repository and separate target schema.
Thanks to SOX we can't have one person be able to update both environments.
I am thinking of using UNIX scripts to run MDL Exports and MDL Imports and OMBPLUS to do the deployments.
Has anyone implemented such a process?
My other thought was to use the 'Deploy to File' method and OMBPLUS to do the actual deployment.
Any pros and cons to either method?
Any and all opinions are most welcomed.
Many thanks.
Gary

Upon further research it appears I'll need a combination of exp/imp and OMBPlus to do what I need. Please correct any of the below assumptions:
1 - I need to use exp/imp to get the object definitions from the Test repository to Production repository.
2 - I need to do a 'Deploy to File' through the OWB Client on the Test repository objects to generate the deployment files.
3 - I then need to use OMBPlus to deploy the objects on the Production side.
Questions:
1 - Is there a way to get the 'Deploy to File' output in a command line environment so it can be scripted in UNIX?
2 - Is there a way to set up a 'Deploy Only' type user so the Operators can ONLY deploy objects and NOT change anything?
Thanks very much for the help. I'm very interested in how other companies are handling the separation of duties with SOX and these moves from Test to Production.
Till then...
Gary

Best Practice for Production environment

Hello everyone,
can someone share the best practice for a production environment? or is there a SAP standard best practice to follow in a Production landscape?
i understand there are Best practices available for Implementation , Migration and upgrade. But, i was unable to find one for productive landscape
thanks.

Hi Siva,
What best practise are you looking for ? If you can be specific on your question we could provide appropriate response.
From my basis experience some of the best practices.
1) Productive landscape should have high availability to business. For this you may setup DR or HA or both.
2) It should have backup configured for which restore has been already tested
3) It should have all the monitoring setup viz application, OS and DB
4) Productive client should not be modifiable
5) Users in Production landscape should have appropriate authorization based on SOD. There should not be any SOD conflicts
6) Transport to Production should be highly controlled. Any transport to Production should be moved only with appropriate Change Board approvals.
7) Relevant Database and OS security parameters should be tested before golive and enabled
8) Pre-Golive , Post Golive should have been performed on Production system
9) EWA should be configured atleast for Production system
10) Production system availability using DR should have been tested
Hope this helps.
Regards,
Deepak Kori

BI Best Practice for Chemical Industry

Hello,
I would like to know if anyone is aware of SAP BI Best Practice for Chemicals.And if so can anyone please post a link aswell.
Thanks

Hi Naser,
Below information will helps you in detail explanation regarding Chemical industry....
SAP Best Practices packages support best business practices that quickly turn your SAP ERP application into a valuable tool used by the entire business. You can evaluate and implement specific business processes quickly u2013 without extensive Customization of your SAP software. As a result, you realize the benefits with less Effort and at a lower cost than ever before. This helps you improve operational efficiency while providing the flexibility you need to be successful in highly demanding markets. SAP Best Practices packages can benefit companies of all sizes, including global enterprises creating a corporate template for their subsidiaries.
Extending beyond the boundaries of conventional corporate divisions and functions, the SAP Best Practices for Chemicals package is based on SAP ERP; the SAP Environment, Health & Safety (SAP EH&S) application; and the SAP Recipe Management application. The business processes supported by SAP Best Practices for Chemicals encompass a wide range of activities typically found in a chemical industry
Practice:
u2022 Sales and marketing
u2013 Sales order processing
u2013 Presales and contracts
u2013 Sales and distribution (including returns, returnables, and rebates, with quality management)
u2013 Inter- and intracompany processes
u2013 Cross-company sales
u2013 Third-party processing
u2013 Samples processing
u2013 Foreign trade
u2013 Active-ingredient processing
u2013 Totes handling
u2013 Tank-trailer processing
u2013 Vendor-managed inventory
u2013 Consignment processing
u2013 Outbound logistics
u2022 Supply chain planning and execution Supply and demand planning
u2022 Manufacturing planning and execution
u2013 Manufacturing execution (including quality management)
u2013 Subcontracting
u2013 Blending
u2013 Repackaging
u2013 Relabeling
u2013 Samples processing
u2022 Quality management and compliance
u2013 EH&S dangerous goods management
u2013 EH&S product safety
u2013 EH&S business compliance services
u2013 EH&S industrial hygiene and safety
u2013 EH&S waste management
u2022 Research and development Transformation of general recipes
u2022 Supplier collaboration
u2013 Procurement of materials and services (Including quality management)
u2013 Storage tank management
u2013 E-commerce (Chemical Industry Data Exchange)
u2022 Enterprise management and support
u2013 Plant maintenance
u2013 Investment management
u2013 Integration of the SAP NetWeaver Portal component
u2022 Profitability analysis
More Details
This section details the most common business scenarios u2013 those that benefit most from the application of best practices.
Sales and Marketing
SAP Best Practices for Chemicals supports the following sales and marketingu2013related business processes:
Sales order processing u2013 In this scenario, SAP Best Practices for Chemicals supports order entry, delivery, and billing. Chemical industry functions include the following:
u2022 Triggering an available-to-promise (ATP) inventory check on bulk orders after sales order entry and automatically creating a filling order (Note: an ATP check is triggered for packaged material.)
u2022 Selecting batches according to customer requirements:
u2022 Processing internal sales activities that involve different organizational units
Third-party and additional internal processing u2013 In this area, the SAP Best Practices for Chemicals package provides an additional batch production step that can be applied to products previously produced by either continuous or batch processing. The following example is based on further internal processing of plastic granules:
u2022 Purchase order creation, staging, execution, and completion
u2022 In-process and post process control
u2022 Batch assignment from bulk to finished materials
u2022 Repackaging of bulk material
SAP Best Practices for Chemicals features several tools that help you take advantage of chemical industry best practices. For example, it provides a fully documented and reusable prototype that you can turn into a productive solution quickly. It also provides a variety of tools, descriptions of business scenarios, and proven configuration of SAP software based on more than 35 years of working with the
Chemical industry.
SAP Functions in Detail u2013 SAP Best Practices for Chemicals
The package can also be used to support external toll processing such as that required for additional treatment or repackaging.
Tank-trailer processing u2013 In this scenario, SAP Best Practices for Chemicals helps handle the selling of bulk material, liquid or granular. It covers the process that automatically adjusts the differences between the original order quantities and the actual quantities filled in the truck. To determine the quantity actually filled, the tank trailer is weighed before and after loading. The delta weight u2013 or quantity filled u2013 is transmitted to the SAP software via an order confirmation. When the delivery for the sales order is created, the software automatically adjusts the order quantity with the confirmed filling quantity.The customer is invoiced for the precise quantity filled and delivered.
Supply Chain Planning and Execution
SAP Best Practices for Chemicals supports supply chain planning as well as supply chain execution processes:
Supply and demand planning u2013 Via the SAP Best Practices for Chemicals package, SAP enables complete support for commercial and supply-chain processes in the chemical industry, including support for integrated sales and operations planning, planning strategies for bulk material, and a variety of filling processes with corresponding packaging units. The package maps the entire supply chain u2013 from sales planning to material requirements planning to transportation procurement.
Supplier Collaboration
In the procurement arena, best practices are most important in the following
Scenario:
Procurement of materials and services:
In this scenario, SAP Best Practices for Chemicals describes a range of purchasing processes, including the following:
u2022 Selection of delivery schedules by vendor
u2022 Interplant stock transfer orders
u2022 Quality inspections for raw materials, including sampling requests triggered
by goods receipt
Manufacturing Scenarios
SAP Best Practices for Chemicals supports the following sales and
Manufacturingu2013related business processes:
Continuous production u2013 In a continuous production scenario, SAP Best Practices for Chemicals typifies the practice used by basic or commodity chemical producers. For example, in the continuous production of plastic granules, production order processing is based on run-schedule headers. This best-practice package also describes batch and quality management in continuous production. Other processes it supports include handling of byproducts,co-products, and the blending process.
Batch production u2013 For batch production,
SAP Best Practices for Chemicals typifies the best practice used by specialty
chemical producers. The following example demonstrates batch production
of paint, which includes the following business processes:
u2022 Process order creation, execution, and completion
u2022 In-process and post process control
u2022 Paperless manufacturing using XMLbased Process integration sheets
u2022 Alerts and events
u2022 Batch derivation from bulk to finished materials
Enterprise Management and Support
SAP Best Practices for Chemicals also supports a range of scenarios in this
area:
Plant maintenance u2013 SAP Best Practices for Chemicals allows for management
of your technical systems. Once the assets are set up in the system, it focuses on preventive and emergency maintenance. Tools and information support the setup of a production plant with assets and buildings.Revenue and cost controlling u2013 The package supports the functions that help you meet product-costing requirements in the industry. It describes how cost centers can be defined, attached
to activity types, and then linked to logistics. It also supports costing and settlement of production orders for batch and continuous production. And it includes information and tools that help you analyze sales and actual costs in a margin contribution report.
The SAP Best Practices for Chemicals package supports numerous integrated
business processes typical of the chemical industry, including the following:
u2022 Quality management u2013 Supports integration of quality management concepts across the entire supplychain (procurement, production, and sales), including batch recall and complaint handling
u2022 Batch management u2013 Helps generate batches based on deliveries from vendors or because of company production or filling, with information and tools for total management of batch production and associated processes including batch derivation, batch information cockpit, and a batchwhere- used list
u2022 Warehouse management u2013 Enables you to identify locations where materials
or batch lots are stored, recording details such as bin location and other storage information on dangerous goods to help capture all information needed to show compliance with legal requirements
Regards
Sudheer

Best practice for a deplomyent (EAR containing WAR/EJB) in a productive environment

Hi there,
I'm looking for some hints regarding to the best practice deployment in a productive
environment (currently we are not using a WLS-cluster);
We are using ANT for buildung, packaging and (dynamic) deployment (via weblogic.Deployer)
on the development environment and this works fine (in the meantime);
For my point of view, I would like to prefere this kind of Deploment not only
for the development, also for the productive system.
But I found some hints in some books, and this guys prefere the static deployment
for the p-system.
My question now:
Could anybody provide me with some links to some whitepapers regarding best practice
for a deployment into a p-system ??
What is your experiance with the new two-phase-deploment coming up with WLS 7.0
Is it really a good idea to use the static deployment (what is the advantage of
this kind of deployment ???
THX in advanced
-Martin

Hi Siva,
What best practise are you looking for ? If you can be specific on your question we could provide appropriate response.
From my basis experience some of the best practices.
1) Productive landscape should have high availability to business. For this you may setup DR or HA or both.
2) It should have backup configured for which restore has been already tested
3) It should have all the monitoring setup viz application, OS and DB
4) Productive client should not be modifiable
5) Users in Production landscape should have appropriate authorization based on SOD. There should not be any SOD conflicts
6) Transport to Production should be highly controlled. Any transport to Production should be moved only with appropriate Change Board approvals.
7) Relevant Database and OS security parameters should be tested before golive and enabled
8) Pre-Golive , Post Golive should have been performed on Production system
9) EWA should be configured atleast for Production system
10) Production system availability using DR should have been tested
Hope this helps.
Regards,
Deepak Kori

Best Practice for Production IDM setup

Hi, what is the best practice for setting up prodcution IDM:
1. Connect IDM prod to ECC DEV,QA and Prod or
2. Connect IDM prod to ECC prod only and Connect IDM dev to ECC Dev and QA.
Please also specify pros and cons for both options if possible.
Thanks in advance,
Farhan

We run our IDM installation as per your option 2 (Prod and non-prod on separate instances)
We use HCM for the source of truth in production and have a strict policy regarding not allowing non HCM based user accounts. HCM creates the SU01 record and details are downloaded to IDM through the LDAP extract. Access is provision based on Roles attached to the HCM Position in IDM. In Dev/test/uat we create user logins in IDM and push the details out.
Our thinking was that we definitely needed a testing environment for development and patch testing, and it needs to be separate to production. It was also ideal to use this second environment for dev/test/uat since we are in the middle of a major SAP project rollout and are creating hundreds of test and training users with various roles and prefer to keep this out of a production instance.
Lately we also created a sandpit environment since I found that I could not do destructive testing or development in the dev/test/uat instance because we were becoming reliant on this environment being available. Almost a second production instance - since we also set the policy that all changes are made through IDM and no direct SU01 changes are permitted.
Have a close look at your usage requirements before deciding which structure works best for you.

Best practices for promotions to production

My company's production environment is way to lose, I need to implement some controls. My analysts keep fouling up the production objects. Does anyone know of best practices for an organization rolling out production changes?
thanks

Yes you can. With SOA 11g, you can create deployment profiles to change poperties during deployment. You can also build your own deployment mechanism, as I did.
http://orasoa.blogspot.com/2009/04/new-oracle-soa-build-server-osbs.html
Marc

Best practices for loading apo planning book data to cube for reporting

Hi,
I would like to know whether there are any Best practices for loading apo planning book data to cube for reporting.
I have seen 2 types of Design:
1) The Planning Book Extractor data is Loaded first to the APO BW system within a Cube, and then get transferred to the Actual BW system. Reports are run from the Actual BW system cube.
2) The Planning Book Extractor data is loaded directly to a cube within the Actual BW system.
We do these data loads during evening hours once in a day.
Rgds
Gk

Hi GK,
What I have normally seen is:
1) Data would be extracted from APO Planning Area to APO Cube (FOR BACKUP purpose). Weekly or monthly, depending on how much data change you expect, or how critical it is for business. Backups are mostly monthly for DP.
2) Data extracted from APO planning area directly to DSO of staging layer in BW, and then to BW cubes, for reporting.
For DP monthly, SNP daily
You can also use the option 1 that you mentioned below. In this case, the APO cube is the backup cube, while the BW cube is the one that you could use for reporting, and this BW cube gets data from APO cube.
Benefit in this case is that we have to extract data from Planning Area only once. So, planning area is available for jobs/users for more time. However, backup and reporting extraction are getting mixed in this case, so issues in the flow could impact both the backup and the reporting. We have used this scenario recently, and yet to see the full impact.
Thanks - Pawan

Procedure/Best Practices - For providing SAP BASIS SUPPORT

Hi All,
I need information on SAP BEST PRACTICES on providing BASIS SUPPORT for SAP4.7.
If you can give me any link or document regarding this that would be of great help to me.
Expecting the replies...
Thanks
Cheenu

Hi Cheenu,
I'm not quite sure what do you mean by "providing SAP BASIS SUPPORT".
Run SAP roadmaps describe the recommended methodology for End-to-end operations of SAP solution, including technical operations (basis). You can check them at service.sap.com/roadmaps (go to "Run SAP Roadmap"). If you need a list of tasks you should perform in a scope of solution operations you'll find it there as well.
SAP solution management is based on ITIL methodology. You can find more about ITIL at www.best-management-practice.com/IT-Service-Management-ITIL/.
Hope this helps.
KR,
Grigor

SAP Best Practices for Sales Support(CAS)

Hi,
Pl provide me the SAP Best Practices for Sales Support(CAS).
Regards
Ravi

Dear Ravi
Please check these links
[Sales Support: Computer-Aided Selling |http://help.sap.com/saphelp_40b/helpdata/en/10/748534c4603c34e10000009b38f83b/frameset.htm]
[Sales Support : Computer Aided Selling|http://help.sap.com/printdocu/core/Print46c/EN/data/pdf/SDCAS/SDCAS.pdf]
thanks
G. Lakshmipathi

Best practice for managing a Windows 7 deployment with both 32-bit and 64-bit?

What is the best practice for creating and organizing deployment shares in MDT for a Windows 7 deployment that has mostly 32-bit computers, but a few 64-bit computers as well? Is it better to create a single deployment share for Windows 7 and include both
versions, or is it better to create two separate deployment shares? And what about 32-bit and 64-bit versions of applications?
I'm currently leaning towards creating two separate deployment shares, just so that I don't have to keep typing (x86) and (x64) for every application I import, as well as making it easier when choosing applications in the Lite Touch installation. But I know
each deployment share has the option to create both an x86 and x64 boot image, so that's why I am confused.

Supporting two task sequences is way easier than supporting two shares. Two shares means two boot media, or maintaining a method of directing the user to one or the other. Everything needs to be imported or configured twice. Not to mention doubling storage
space. MDT is designed to have multiple task sequences, why wouldn't you use them?
Supporting multiple task sequences can be a pain, but not bad once you get a system. Supporting app installs intelligently is a large part of that. We have one folder per app install, with a wrapper vbscript that handles OS detection. If there are separate
binaries, they are placed in x86 and x64 subfolders. Everything runs from one folder via the same command, "cscript install.vbs". So, import once, assign once, and forget it. Its the same install package we use for Altiris, and we'll be using a Powershell
version of it when we fully migrate to SCCM.
Others handle x86 and x64 apps separately, and use the MDT app details to select what platform the app is meant for. I've done that, but we have a template for the vbscript wrapper and its a standard process, I believe its easier. YMMV.
Once you get your apps into MDT, create bundles. Core build bundle, core deploy bundle, Laptop deploy bundle, etcetera. Now you don't have to assign twenty apps to both task sequences, just one bundle. When you replace one app in the bundle, all TS'es are
updated automatically. Its kind of the same mentality as active directory. Users, groups and resources = apps, bundles and task sequences.
If you have separate build and deploy shares in your lab, great. If not, separate your apps into build and deploy folders in your lab MDT share. Use a selection profile to upload only your deploy side to production. In fact I separate everything (except
drivers) into Build and deploy folders on my lab server. Don't mix build and deploy, and don't mix Lab/QA and production. I also keep a "Retired" folder. When I replace an app, TS, OS, etcetera, I move it to the retired folder and append "RETIRED - " to the
front of it so I can instantly spot it if it happens to show up somewhere it shouldn't.
To me, the biggest "weakness" of MDT is its flexibility. There's literally a dozen different ways to do everything, and there's no fences to keep you on the path. If you don't create some sort of organization for yourself, its very easy to get lost as things
get complicated. Tossing everything into one giant bucket will have you pulling your hair out.

Best Practice for Conversion Workflow

Hello,
I'm converting video files from our "home grown" virtual media reserve to iTunes U. Some of the files are in RM format, some are already compressed .mov's (not H.264) and some I have the original DV files for.
Anyone out there have a best practice for converting these file types for posting to iTunes U? I have Final Cut Studio (Compressor), QT Pro and Squeeze available to me.
Any experience you have with this would be helpful.
Thanks,
Jeana

For converting old files to a podcast compatible video and based on the machine you have, consider elgato turbo.264. It is a fairly priced "co-processor" for video conversion. It is comprised of an application and a small USB device with a encoder chip in it. In my experience, it is the fastest way to create podcast video files. The amount of time that you will save will pay for the device quickly (about $100). Plus it does batch conversion of any video that your system currently plays through QuickTime. it has all the necessary presets and you can create your own. It has a few minor limitations such as not supporting (at this moment) enhanced podcasting features such as chapter markers and closed-captions but since you have old files for conversion, that won't matter.
For creating new content, the workflow varies a lot. Since you mention MP3s, I guess you are also interested in audio files. I would stick with GarageBand, especially if you are a beginner plus it supports enhanced podcasts.
In any case the most important goal is to have the simplest and fastest way to go from recording to publication. The less editing the better. To attain that, the best methods will require the largest investments. For example, for video production the best way is to produce the content live so when you finish recording it is only a matter of encoding and publishing. that will require the use of a video switcher that can ingest at least one video camera and a computer output to properly capture presentation material. That's the minimum. there are several devices that can do this for you. Some are disguised PCs and some connect to a PC for tapeless recording. You can check the Tricaster, which I like but wish it was a Mac and not a Windows Xp PC. Other routes may include video mixers from manufacturers like Edirol, Pansonic or Sony connected to a VTR or directly to a Mac for direct-ti-disc capture. I f you look at some of the content available in iTunes U, you will see what I explain here. This workflow requires preparation and sufficient live support but you will have your material ready for delivery almost immediately after the recorded event. No editing required. Finally, the most intensive workflow is to record everything separately and edit it later, which is extremely time consuming.

Best Practices for APO Production Support

Similar Messages

Maybe you are looking for