Basis and others: 2013

How to Evaluate Prospective Clients and Choose the Best Ones

You want good clients and not bad clients, but how can you tell the difference?

If you’ve been a freelance web designer for a while (and especially if you have a strong online presence), this has probably happened to you. Out of the blue, you get an email asking about your web design services from someone you have never heard of working for a company you have never heard of.

Yay! You might think it’s time for a celebration. But as an experienced freelancer, you know to be careful. You know that it’s important to evaluate prospective clients. You shouldn’t agree to work for every single prospect who contacts you.

First of all, you want to make sure that their inquiry is legitimate. And you should also consider whether they are the right client for you.

In this post, I’ll list five steps to help you evaluate a prospective client. At the end of the post, share your tips about how you evaluate clients.

Step 1: Know Your Ideal Client

It may surprise you to learn that the first step to evaluating a client is to know your own business goals better.

If you haven’t already done so, you should build a profile of the type of clients you prefer to work with. Here are some questions to ask yourself:

Do I prefer a laid-back client, or a more formal relationship?
Are my clients my collaborators, or do I prefer clients with a more hands-off approach?
Is my ideal client technologically savvy or do they need some help with technology?
Is there an industry that I usually work in?
What type of web design do I typically do (and what type do I prefer to do)?

Once you understand what type of client you prefer to work with, you can take steps to target that type of client in your marketing. Most importantly, you can use your ideal client profile to evaluate potential clients.

Step 2: Check the Social Profile

One of the first steps I always take when someone contacts my about my freelancing services is to look at their social media profiles. While it’s true that once in a while you’ll encounter someone who has no social media presence at all, most people do have some sort of profile on one or more of the social media platforms.

Here are the social sites I look at and what I look for:

LinkedIn. You can learn a lot about a prospect by looking at their LinkedIn profile. You can tell what their area of expertise is, what their past employment has been, and even what their skills are. I recommend also looking for recommendations.
Twitter. If the person has a Twitter profile, I look to see whether the profile is filled out. Do they have an image with their profile? Does their profile link back to their website? Finally, I look at what sort of tweets they are sharing. Are the tweets professional?
Google+. Google+ is known for a more technical audience, so a presence here could indicate a more Internet-savvy prospect. Again, I look to see if the profile is filled out and whether it links back to a website. It’s also important to look at what the prospect is sharing.

If the person’s social media profiles or shares are unprofessional, that can be a red flag about doing business with them.

Step 3: Check the Existing Website

If the prospect passes the social media hurdle, it’s time for me to look at their website. Since you’re a web designer and presumably the client is interested in hiring you to change their web design, you don’t necessarily want to be too critical of their current design. In fact, they may not have a website yet.

If the client has a website, here’s what I look for:

Domain. Does the client host the website on their own domain? It’s a huge red flag if the client website is hosted on someone else’s domain like WordPress or Tumblr.
About page. I always read the About page of a prospective client’s website to learn what the client thinks is important about their business.
Blog. If they have a blog attached to their website, I read a few of their most recent posts.
The rest. You may also want to read about the company’s product or service, any executive bios they have posted, and anything else on their site that catches your attention.

As you can see, a client’s website can tell you a lot.

Step 4: Check the Online Reputation

Another step you can take to check out a prospective client is to find out what others are saying about their company. Your first line of defense is the search engine. I typically type in a phrase like:

“Complaints about [company name]“

“Review of [product name]“

Even though the results will indicate what clients think of your prospect’s company, they may indirectly indicate how the company will treat a freelancer. After all, if they don’t treat their own clients well, how likely is it that they will treat a freelancer well?

Here are some other places to check:

Better Business Bureau. In the United States and Canada, the Better Business Bureau maintains a directory of accredited businesses and charities. They also keep a listing of complaints against businesses. While not every business is listed here, many are.
Google Apps MarketPlace. If the company creates software applications, you may able to find customer reviews on the Google Apps MarketPlace.
GlassDoor. Officially, this site is for potential employees of a company. However, if they treat their employees badly, how might they treat a freelancer?

Step 5: Ask Questions

The final step in evaluating a potential client is to ask questions about the project. You may even wish to schedule a phone call or (if you live nearby) a face-to-face meeting. An advantage to doing all the homework in Steps 1 to 4 is that by now you already know a great deal about the prospective client.

If you still have questions about the client, it’s important to ask them before you start to work with them. Naturally, you want to get all of the specifics about the project you will be working on.

To get an idea of how the client works, you can also ask the following questions:

Do they prefer frequent progress updates, or will you work mostly independently?
Will they be available to answer questions?
What is their preferred method of communication (IM, phone, or email)?

A final filter to help you determine whether a client is a good fit is prepayment. I always recommend that freelancers require a new client to pay some or all of the project fee upfront. Most good clients will have no problem doing so.

16420 - Problems with SAPLPD

Symptom

Problems occur during remote printing or during frontend printing with SAPLPD.

Other Terms

SAPLPD, network printing

Reason and Prerequisites

Solution

IMPORTANT INFORMATION: SAP now only supports SAPLPD for frontend printing in Releases prior to 4.6C.

For remote printing with access method 'S' or 'U', use the new, release-independant SAPSPrint tool. Refer to Note 894444 for more information.

For frontend printing in releases higher than 4.6B, use access method 'G' (see Note 821519).

Refer to Note 841175 for patches for access method 'G'.
Refer to Note 927074 for patches for SAPSprint.
Refer to Note 328252 for SAPLPD patches for frontend printing in Releases prior to 4.6C.

1069483 - Error occured in CreateDCW

Symptom

The system issues an error message in the trace of the sapwin.dll:
Error: CreateDCW failed: The operation completed successfully. Or the system issues an equivalent error message that corresponds to the language setting.

After this error occurs, you cannot print on the affected printer until SAPSprint service restarts.

Other Terms

CreateDCW, CreateDC, SAPSprint, StartPage failed, EndPage failed

Reason and Prerequisites

The problem can only occur if you use a SAPWIN device type to print. The output is executed through a Windows API using a Windows printer driver. If an error occurs with one of the printer drivers (for example, memory is not released), the problem described above may occur. This error occurs mainly when you call CreateDC but it may also occur in other Windows GDI calls. The messages in the trace are similar to those described above.

This problem is not caused by the SAP source code and therefore an immediate correction is not possible. The problem is the print drivers that are not designed for mass processing.
In addition, analyzing this problem is very difficult because it cannot be reproduced and because it occurs only after the service experienced a long runtime. You can use the workarounds described below to at least minimize the consequences of the problem.

Solution

SAP recommends the following solution:

1. Apply the latest SAPSprint patch. For more information, also see Note 927074.

2. Set the option "Use OMSPRINT" to the value 1. The option is available as of SAPSPrint 720 patch 5; as of SAPSprint patch 6, you can edit this on the "SAPWIN Processing" tab page of the "Options Editor". If you activate the option, the critical processing is moved to a separate process. This is restarted and ended again for each print job. This should prevent the problem.

3. If possible, schedule the restart of the service for a time when printing is not taking place. The probability of the problem occurring increases as the runtime of the service increases.

4. As a result of the automatic restart of SAPSprint Services, the SAPSprint process is available again after a very short time. However, due to the short period of unavailability, all printers that are defined on the SAPSprint server in the SAP system are blocked for about 5 minutes. This is not necessary and, depending on the amount of print requests, may lead to an accumulation of jobs. The following profile parameters may affect how long a printer is blocked for:               rspo/tcp/retrytime = 1
              rspo/host_spool/check_retries = 5
              rspo/lpq/temp_disable_time = 1
              If you shorten retrytime and temp_disable_time (for example, to 1), this prevents the printers being blocked in almost all cases. You must change these profile parameters only if you are using SAPSprint as the print server. If you use another print server that does not automatically restart, you must use the default values.
              SAPSprint restarts automatically after the CreateDC error occurs.  If you do not want this to occur for whatever reason, you can deactivate it by setting the option "IgnoreDCError" to 1.  Note: Automatic restart works only within certain limits. If the problem occurs too often, the system response is no longer as required.

1054561 - Output sequence is lost when you use SAPSprint

Symptom

When you use SAPSprint on a print server, the system may not output requests in the required sequence.

Other Terms

SAPSPrint, sequence, 'Process requests sequentially', sorting

Reason and Prerequisites

First, make sure that indicator 'Process requests sequentially' is set for the output device in transaction SPAD. This is the basic prerequisite to ensure that the requests leave the SAP system in the correct order.

When you process the print request in SAPSprint, the sequence may be lost in various places. This is not normally the case. However, this may occur in rare cases due to the design of SAPSprint. The reason for this is parallel processing and receiving print requests in different operating system threads. A task that was started later in a separate thread may end earlier than a task that was started earlier in a different thread. The threads 'overtake' each other.

Solution

Two parameters are available to adjust the behavior. However, both use serialization to slow down processing of print requests. Therefore, you should change the default behavior only if the sequence is relevant and if the sequence problem occurs.

Both parameters are provided on the 'SAPSprint Processing' page of the option editor (see Note 85469). First, select the 'Enforce serialization' option. If you use this option in the internal processing queue, the system retains the sequence by blocking a print job that was received later until a job that was received earlier has been placed in the queue.

If the sequence problem still occurs after this, deselect the 'Use separate thread for job reception' option. This ensures that the complete print job is received by one single thread. Overtaking can no longer occur during reception. However, this causes reception to be restricted to one single thread. This may cause reception problems for large print jobs because the thread is blocked for too long. Therefore, you should set this option only if it is absolutely necessary.

927074 - Patches for SAPSprint

Symptom

You require the latest version of the files for the Windows print server (Note 894444).

Other Terms

SAPSprint, SAP GUI for Windows, SAPPDFPRINT

Reason and Prerequisites

Release information 640:
Patch 17 (file version 1017) was the last version for Release 640. This release is no longer available.

Release information 710:
Patch 24 (file version 1024) is the last version for Release 710.
This release is no longer available.

Release information 720 and 730:

You can download SAPSprint patches as a self-extracting executable file from SAP Service Marketplace. Call http://service.sap.com/patches and navigate as follows:

           1.  Browse our Download Catalog (on the left)
           2.  SAP Frontend Components (on the right)
           3.  SAPSPRINT (on the right)
           4.  SAPSPRINT <Release> (on the right)
           5.  Win32 (on the right)

Start the program. After you enter the installation path, the system asks for the TCP/IP port and another path for storing log files. Normally, the default setting of 515 is suitable for the port. You should only change this setting if the Windows TCP/IP print service is also running on the computer. The SAPSprint Windows service starts as soon as the installation is over. By default, the files are copied to the directory C:\Programme\SAP\SAPSPrint or C:\Programme (x86)\SAP\SAPSPrint with 64bit Windows.

By calling 'sapsprint -h', you can display a short history of the patch changes.

If you use PDFPRINT, also refer to SAP Note 1490835. The releases of SAPSprint and PDFPRINT must be compatible; that is, there cannot be any combination of 720 and 730.

Solution

Download and execute the installation file for the required version.

Header Data

Released On

11.09.2012 15:49:57

Release Status

Released for Customer

Component

BC-CCM-PRN Print and Output Management

Other Components

BC-FES-GUI Graphical User Interface

Priority

Correction with high priority

504952 - Composite note regarding spooling and printing

Symptom

This note lists the most important notes that are helpful when analyzing print problems.

Other Terms

Spool, SPAD, SP01

Reason and Prerequisites

Solution

General information

  18274    Problem message incomplete -> Spool/Printer/Fax
  26009    R/3 System does not print, first steps
164323    Where do I find information on the topic of printing?

No print output

  1336   Spooler reports database I/0 error
   7140   Problem printing very large lists

Output is incorrect

   2774  Umlauts (national special character) become '#'
   3085  Unwanted empty pages between the printouts
   3102  SAPscript print problems (standard page formats)
   4572  No output on UNIX despite 'finished' status
  11214  Print problems: Changes SPAD/RSTXSCRP/RSTXCPAG
  11733  WRITE or(!) ROLLBACK WORK
  27799  Turn off unwanted form feeds
121898   Euro character from SAPscript as of 4.6A
183948  Identical output on PCL-5,PostScript,SAPWIN
409339   Spool requests with ABAP lists with more than 255 columns

Remote printing, network printing, front-end printing

   2863   Which LPD is required for remote printing?
  10758   SAPSprint or SAPLPD cannot be reached.  What should be done?
  12550  Problems with remotely connected printers (WAN)
  12552  Request for debugging information for SAPLPD
  13350  Font control via SAPLPD
  13376  Spooler prints slowly or has stuck entries
  14561  Use SAPSprint/SAPLPD and Barcode DLL to print barcodes
  16420   Problems with SAPLPD
  19291   Setting up printers under UNIX
  21738   Device type SAPWIN
  25941  SAP System does not find host name
  39405  Print on UNIX LPD: "Malformed Address"
  41913  Parameters when calling SAPLPD/log files
  42268  Operate SAPLPD as a service on Windows NT/2000
  44009  SAPLPD or TCP/IP Print server (from UNIX and R/3)
  49698   Connection problems with SAPLPD
  61905  Supply SAPLPD print data
  64628  Using network printers from R/3
  85469  Options for the SAPSprint print server tool
102836   Creating the LPRINT trace
128105   Frontend printing (collective note)
150533   Printing in Windows Terminal Server (WTS)
311037   Printing via e-mail
317851  Creating PDF format using the SAP spooler in 4.6C/4.6B/4.5B
323736   Restrictions with "PDF print" through spooler
328252  Support Packages for SAPLPD and LPRINTG
351230  Frontend printing with HTML GUI/WebGUI (up to Rel. 6.20)
351492  Setting up frontend printing as of Release 4.6B
379515  Troubleshooting frontend printing (access method 'F')
383703  Corrections in SAPLPD (collective note)
385794  Connection problems with network access methods
509681   Front-end print from work process update task
513352   Printing by e-mail (update)
529750   Printing to a local device fails

Spool system, configuration, functionality

  4364   Spooling and printing is *very* slow
   5799  How can you view prepared print data?
   6753  Printing in file (to magnetic tape) or elsewhere
  12260 File I/O error when accessing TemSe object File-IO-error
  13525  Requesting a level 2 trace from spool work process
  15355  Command line parameter for access type L
  16307  Processing times when printing
  16410  Attaching to existing spool requests
  16875  TemSe objects do not match TemSe files
  19706   Tuning the Spooler
  20176  Where is the spool request saved?
  21469  Requesting a printer trace
  21661  TemSe input/output to file that is not open
  41547  How does report RSPO0041 work?
  48284  Creating more than 32000 spool requests
  48400  Reorganization of TemSe and Spool
  64337  Transporting output devices (printers)
  67055  Explanation of syslog message xrtab(?)->? for ????
  81064  Spool trace as of Release 4.0
  85318  Appending documents to existing spool requests
  95774  Analyze print problem w/ UNIX, access method L
  98065  Spool consistency check with RSPO1043 as of 4.0A
108799  How many spool work processes for each instance?
118057   Flexible Configuration of the Spool Service
119147   Spool: Authorizations
130978   RSPO1041 - Replacement for RSPO0041
161516   Printing into a file or anywhere else in NT
352269   Spool kernel patches (collective note)
371919  Internal operation of WEB printing
502604   Problems with external Output Management Systems

Device types, printer languages

   1381  Rerouting a print request to another printer
  3166  Name range for customer-modified printer types
  5196   Printing bar codes with SAPscript
  8928   List of supported printers/device types
  12462  How can I define a new printer font?
  17054  How to copy or change a device type
  17895  Adapting print list formats for customers
  76749  How can you delete a complete device type?
  94233  MICR font support
  96102  Information on double-sided print with SAPscript
143375  Choice of paper tray for printing lists as of Release 4.5
189618   Paper tray and print mode for Smart Forms

10758 - SAPSprint or SAPLPD cannot be reached. What should be done?

Symptom

Print requests in R/3 are marked as FAULTY. The system log contains the message "Connection to SAPLPD/LPD cannot be established".

(This note does NOT deal with the problem of requests not being processed, for instance requests remaining in the R/3 spool in status "Waits". It deals only with cases where requests get the status "Error".)

Other Terms

Reason and Prerequisites

a) There is a network problem.

b) The configuration in R/3 is incorrect. To begin with, however, here is some information on terms used. The formatting computer is the computer on which the spool work process runs and in whose local system log the error message was located. The formatting computer sends the data after formatting to another computer which is then to print the data. This computer is the switching computer.

Solution

Carry out the following tests, log the results of the individual steps and communicate them to SAP Support if the problem has to do with the SAP system.

1. Is the "switching computer" a "printer box" located between the network and the printer or is it a network card in the printer itself?               Although such boxes behave like actual computers, they cannot store large amounts of data temporarily. If a request is currently being printed, the box will not be able to set up an additional connection.
              The second print request is rejected and ends with this error.
              We urgently recommend that you operate these boxes only from the host spool, as this has more time and resources available. Therefore, set the output device in SPAD with access method 'L' or 'C' or using a print server with access type 'S' or 'U'.
              A direct connection from the R/3 system will result in these messages being issued repeatedly.

2. Now establish the name by which the computer was addressed. You will find this in the error message in the system log.               Is this name correct?
              If NOT:
              Correct the name using transaction SPAD. If the name is too long, use an alias in SPAD. Choose the 'Long Host Name' button, which is to the right of the 'Destination Host' field and enter the long name.

3. Log on as <sid>adm to the computer to the computer on which the spool work process is running. Now call the command "ping" from a command line with the computer name given in the system log as the argument.               If "ping" issues individual packages with runtimes, the connection works.
              If "ping" does not respond, it should run for just over a minute. Then you can terminate it. A statistics record is issued. If this record contains the message "100% packet loss", this means that there is either no connection to the other computer or else TCP/IP is not running there.
              Correct this problem and then try to print again.

4. Configure the printer concerned as a remote printer in the operating system and try to print something on the remote printer using the usual operating system commands (lp, lpr). If this does not work, and the software used for the remote printer is not SAPSprint (see Note 894444) or SAPLPD, the error does not involve SAP components. Solve this problem first and then try again to print something from the SAP System.

5. The next test requires an FTP server attached to the switching computer. If this is a PC, you may need to start it manually.               Enter "ftp <switching computer> on the formatting computer.
              If problems are reported, start by eliminating these problems. Then try to print again.
              Normally, the FTP prompts you to enter a user name and password for the switching computer. Make valid entries here.
              Now transfer a file of approximately 10 Kbytes from the formatting computer to the switching computer: put <filename>
              The file is created on the switching computer. If this process terminates or lasts more than a minute, the network is not stable. Correct this problem before you proceed.
              Check that the data has arrived at the correct computer!
              Log off from FTP with "quit". Delete the test data if required.

6. Then the connection to SAPSprint or another LPD is checked.               Enter the UNIX command "telnet computer 515".
              First, the message "trying ... " appears, followed by "connected to ...".
              If the message "connection refused" appears quite quickly, either SAPSprint or LPD is not running or else the TCP packet is malfunctioning.
              It may help to reboot the switching computer.
              If the message "connection timed out" is issued even though FTP was working, check whether a firewall is preventing the connection from being established for reasons of security. If this is not the case, reboot the switching computer.
              If the connection to telnet has been established ("connected to ..."), you can query the SAPSprint with the command "4 x 1<return>". However, this usually only works if the Telnet command was started on a UNIX platform. If the connection is working, it will identify itself by means of a brief text and close the connection.
              In this case, the connection is working and the problem was presumably a temporary one. You should now be able to print.

tlist | find "<PID>"

If all tests were successful, but the SAPLPD still cannot be reached, a more detailed examination is required.
When you log a problem message, remember to specify the results of each of the above tests, which SAPSprint/SAPLPD/LPD is used, and which network software has been installed.

886102 - System Landscape Copy for SAP NetWeaver BW

Symptom

You want to copy a productive SAP solution landscape to create a non-productive system landscape for testing, quality assurance or other purposes. This copy scenario is referred to as "PRD to NPS". Or you want to copy your productive landscape to a new productive landscape to change some property of the systems, like hardware, operating system or database. This copy scenario is referred to as "PRD to PRD".
Since an SAP solution landscape often consists of multiple components that may or may not be based on NetWeaver, additional component-specific steps that are not described in the general System Copy Guide for SAP Web AS (Homogeneous and Heterogeneous System Copy for SAP Systems Based on SAP Web Application Server (ABAP or JAVA)) are required..

You can subscribe to this Note by adding an e-mail address to your profile. Go to -> http://service.sap.com -> MyProfile (in the header)
-> My personal data -> e-mail. To subscribe to this Note, click on the Subscribe link in the top line of the display. If the Note is changed, you will get an e-mail notification.

Other Terms

System Copy, System Refresh, SAP BW

Reason and Prerequisites

In case you are still in the process of defining your SAP BW system landscape, please read note 184447 and its attachements first, which will give you background information on logical system naming in BW landscapes.

The common procedure for the system copy of an SAP Solution landscape is described in the SAP Best Practice "SAP System Landscape Copy for SAP NetWeaver and SAP Solutions". Please see SAP Note 885343 for more information on that document.

This Note contains supplemental information for copying SAP BW 2.x, 3.x and SAP NetWeaver BW 7.x (formerly known as SAP NetWeaver BI). BW is used as an umbrella term for SAP BW and SAP NetWeaver BW. NetWeaver AS (application server) is used as an umbrella term for Web AS and NetWeaver AS.

The Best Practice document and this Note have a common structure. The procedure described in the Best Practice is divided into several phases and steps that need to be executed for the system copy. This Note only lists the steps of the main document requiring BW-specific information and leaves out the steps that do not need additional actions in a BW system.
When copying an SAP BW system or another SAP solution connected to the BW system, you should work in parallel with the Best Practice and this Note to perform the required system copy steps.

Phase 1: Preliminary Tasks
The Solution part of this Note provides BW-specific enhancements to the steps 1.1 and 1.2. The latter step describes 10 copy scenarios, from which you should choose the one closest to your scenario.

Phase 2: Preparations in Target Environment
Only 1 of the 10 copy scenarios requires BW-specific preparations in the target environment before the copy.

Phase 3: Preparations in Source (Original) Environment
No BW-specific preparations are required in the source (original) environment before the copy.

Phase 4: Copy Process
No BW-specific action is required.

Phase 5: Final Activities in Source (Original) Environment
No final BW-specific activities are required in the source (original) environment after the copy.

Phase 6: Final Activities in Target Environment
All 10 copy scenarios require final BW-specific activities in the target environment after the copy.

Note: In contrast to the Best Practice, this Note uses the term "source system" for the systems that load data to a BW system. The term "original system" is used for the system that is the source of the database copy.

Solution

This section describes the specific steps to be executed in each phase as given in the Best Practice.

Phase 1: Preliminary Tasks

Step 1.1: Get required documentation
To copy an SAP BW system landscape, you need the following documentation:

Newest version of this SAP Note

SAP Best Practice "System Landscape Copy for SAP NetWeaver and SAP Solutions", see SAP Note 885343.

System Copy Guide for SAP Systems Based on SAP NetWeaver 7.x or the System Copy Guide for SAP Web AS ("Homogeneous and Heterogeneous System Copy for SAP Systems Based on SAP Web Application Server") for the underlying Web AS release of your BW 2.x or 3.x system

The following additional SAP Notes:

121163 BDLS: Converting logical system names

369758 BDLS: New functionality and better performance

524554 Storing destinations in the BW environment

184447 Building a BW-system landscape

For Netweaver 7.0 (2004s) BI systems:

961551 70SP09: BDLS: DTPs are not converted

929045 Correction: No PSA-userobj conversion in BDLS

931029 Transformations are not taken into account (BDLS)

981248 Correction: Backup for system copy only for old objects

1000062 70SP13: Conversion of the logical system name

1048947 Corr:Source syst names,pseudo D versions for transformations

1055483 Renaming system in RDA tables (BDLS)

1059278 70SP15: Error in transaction BDLS

1070378 Correction: Hard-coded source system in DataSource program

1097357 7.0 Support Package 16: Transaction BDLS terminates

1107155 70SP17: Transport after system copy

1122853 P17: BDLS does not convert staus manager tables

1135964 70SP17: BDLS with transport connection

1139924 BI7.0(SP18): System names converted incorrectly

1142908 70SP18: BDLS does not convert pseudo D versions

1146596 Correction: DataSources remain after source system deleted

1148403 70SP18: BDLS after early replication

1149141 70SP18: BDLS: log improvements

1156599 Correction: 3.x DataSources are not collected

1168471 Correction:Collecting transformations using emulated DS

1169659 Correction: Process variants not entered by BDLS

1180016 P19:BDLS conversion of PSA text table of status manager

1224597 P19:BDLS:DataSource not converted

1227247 APD: Analysis processes ignored in transaction BDLS

1330317 InfoPackages for DSs missing when collecting for system copy

1271454 Correction: Pseudo D version remains after deletion of SS

1273663 Correction:No PSADELETE/PSAPROCESS for system copy transport

1275544 Correction: TADIR not converted by BDLS

1493814 P25:DTP:PC:Collecting dependent and used Processes

1480336 P25:SDL:Report for deletion of orphan InfoPackages

1357615 70SP22: deletion of used DTPs

1300757 P21:SDL:SS-Deletion and i-message RSM1 632

Details about database-specific preparation and post-processing for heterogeneous system copies can be found in the following SAP Notes:

771209 NW04: System copy (supplementary note)

777024 BW3.0 and BW3.1 System Copy (supplementary note)

Step 1.2: Define a clear copy strategy
The following components belong to a SAP BW system landscape. Unless you are only refreshing an existing landscape copy, these components must be installed and configured in the target landscape:

BW server (SAP NetWeaver AS9
The BW server can be copied using a NetWeaver AS copy procedure. Alternatively you can reload the required data into the BW system after copying the systems serving as BW data sources.

J2EE (as of BW 3.5)

Usually the above components have dependencies on the systems or solutions listed below. To ensure a consistent target landscape, consider copying these components together with the BW landscape. In this case you also need to execute the copy procedure specific to these components.

One or more source systems (SAP systems such as ERP, CRM, SEM, APO, other BW systems, or non-SAP systems) can be linked to a BW system.

The BW system can be source system to one or more other systems (i. e. other BW, SEM or APO systems).

Keep data consistency between BW and all connected systems in mind. Check whether there are additional dependencies that need to be taken into consideration.
Copy Scenarios
Several copy scenarios are possible in a BW environment. Find the scenario that is closest to yours in the below list. This scenario specifies which steps need to be executed.

Scenario group A: You want to copy the whole system group, i.e. a BW system and all its connected source systems.

Scenario A1: You want to copy the entire system infrastructure connected by the BW source system connections (that means the entire system group). You want to replace a productive system group [PRD to PRD].

Scenario A2: You want to copy the entire system infrastructure connected by the BW source system connections (that means the entire system group). You want to create a new non-productive system group or refresh an existing non-productive system group [PRD to NPS, installation or refresh]. If the whole system group is refreshed, the installation and refresh scenario do not differ, since all the systems are overwritten.

Scenario group B: You want to copy the BW system only; the source systems are not copied.

Scenario B1: You want to copy a single BW system of the group; the source system is not copied. You want to replace a productive BW system [PRD to PRD].

Scenario B2: You want to copy a single BW system of the group; the source system is not copied. You want to create a new non-productive copy [PRD to NPS, installation].

Scenario B3: You want to copy a single BW system of the group; the source system is not copied. You want to refresh an existing non-productive BW system by copying the source-system-independent objects from the productive BW system [PRD to NPS, refresh].

Scenario B4: You want to copy a single BW client of the group; the source system is not copied. You want to create a new non-productive client [PRD to NPS, installation, client]. Be aware that this new client cannot be used for BW functionality and only makes sense in special scenarios where a second client on a BW-system might be used for non-BW functionality.

Scenario group C: You want to copy the source system only; the BW system is not copied.

Scenario C1: You want to copy a single source system of a BW system; the BW system is not copied. You want to replace a productive source system of a BW system [PRD to PRD].

Scenario C2: You want to copy a single source system of a BW system; the BW system is not copied. You want to create a new non-productive source system (of an existing non-productive BW system) by copying the productive source system [PRD to NPS, installation].

Scenario C3: You want to copy a single source system of a BW system; the BW system is not copied. You want to refresh an existing non-productive source system (of a non-productive BW system) by copying the productive source system [PRD to NPS, refresh].

Scenario C4: You want to copy a single source system client of a BW system; the BW system is not copied. You want to create a new non-productive source system client (of an existing non-productive BW system) [PRD to NPS, installation, client] or refresh an existing source system client [PRD to NPS, refresh, client].

In the following descriptions, look for the copy phases that are valid for your scenario.

=====================================================================
Scenario A1

You want to copy the entire system infrastructure connected by the BW source system connections (the entire system group). You want to replace a productive system group [PRD to PRD].

Phase 3: Preparations in Source (Original) Environment

Step 3.3: Stop productive operation in the original BW system

SAP NetWeaver 7.0: Stop all daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to stop process chains and real-time data acquisition.

This has to be done before locking the RFC users and before stopping and disabling the other background jobs, e.g. by executing report BTCTRNS1.

Phase 6: Final Activities in Target Environment

Step 6.4: Correct RFC destinations
Modify the RFC destinations. Change the hosts in the appropriate RFC destinations so that they refer to the correct system. See Note 524554.

Since SAP does not support the renaming of productive systems, step 6.7 "Execute Transaction BDLS if you want to rename a system" is omitted here.

Step 6.8: Perform BW-specific adaptations
The following steps are necessary when the host has been changed:

If you are using BI Planning, adjust the server name of the BI Enqueue Server in the administration transaction RSPLSE. For details, see Note 996238.

Reset RFC destination for process chain transport postprocessing. Use transaction RSTPRFC to correct the host.

If you are using a BW Accelerator, refer to SAP Note 1146983 for further instructions.

Step 6.16: Restart productive operation in the target BW system

SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

This has to be done after unlocking the RFC users and after configuring the number of background work processes.

=====================================================================
Scenario A2

You want to copy the entire system infrastructure connected by the BW source system connections (the entire system group). You want to create a new non-productive system group or refresh an existing non-productive system group [PRD to NPS, installation or refresh]. If the whole system group is refreshed, the installation and refresh scenario do not differ since all systems are overwritten.

Phase 3: Preparations in Source (Original) Environment

Step 3.3: Stop productive operation in the original BW system

SAP NetWeaver 7.0: Stop all daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to stop process chains and real-time data acquisition.

This has to be done before locking the RFC users and before stopping and disabling the other background jobs, e.g. by executing report BTCTRNS1.

Phase 5: Final Activities in Source (Original) Environment

Step 5.4: Restart productive operation in the original BW system

SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

This has to be done after unlocking the RFC users but it should be done before restarting and enabling the other background jobs, e.g. by executing report BTCTRNS2.

Phase 6: Final Activities in Target Environment

Step 6.4: Correct RFC destinations
Delete or modify the RFC destinations that point to the original systems. Ensure that an RFC destination exists with the new logical name (which will be assigned in step 6.7) in every connected BW or SAP source system. Change the hosts in the appropriate RFC destinations so that they refer to the correct system. See Note 524554.

Step 6.7: Execute Transaction BDLS if you want to rename a system
If you want to rename one or more of the copied systems, execute transaction BDLS both in the client you wish to rename and in all connected SAP source systems. No other activities (for example, execution of Administrator Workbench / Data Warehousing Workbench (RSA1)) can be performed in the system during conversion!
Read Notes 121163 and 369758 for details about transaction BDLS.

Step 6.8: Perform BW-specific adaptations
The following steps are necessary if the logical system name has been changed:

Execute the following task on the BW system and the SAP source systems.

Reactivate all partner profiles that contain the new logical system name after renaming. Execute transaction WE20 to reactivate the partner profiles. Choose "Partner type LS (logical system)", enter the logical system name of the partner on tab "classification", change the partner status from "I" (inactive) to "A" (active), and save.

Execute the following tasks on the BW system:

Update logical system descriptions in RSA1. For each SAP source system that was converted using BDLS, change the description to match the new logical system name.

Reset generation flag for ODS activation programs. Call transaction RSSGPCLA and highlight program class RSDRO_ACTIVATE. Click #set status# and #OK#. Repeat for program class RSDRO_EXTRACT and RSDRO_UPDATE

If you are using a BW Accelerator, refer to SAP Note 1146983 for further instructions.

Execute the following step if the host has been changed:

If you are using BI Planning, adjust the server name of the BI Enqueue Server in the administration transaction RSPLSE. For details see Note 996238.

Reset RFC destination for process chain transport postprocessing. Use transaction RSTPRFC to correct the host.

Step 6.16: Restart productive operation in the target BW system

SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

SAP NetWeaver 7.0: Stop all daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to stop process chains and real-time data acquisition.

Adjust the table RSLOGSYSDEST for the RFC destinations of the SAP source systems and the myself system. This table contains the relationship between the logical system names and RFC destinations.

If you are using BI Planning, adjust the server name of the BI Enqueue Server in the administration transaction RSPLSE. For details, see Note 996238.

Reset RFC destination for process chain transport postprocessing. Use transaction RSTPRFC to correct the host.

If you are using a BW Accelerator, refer to SAP Note 1146983 for further instructions.

Step 6.16: Restart productive operation in the target BW system

SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

SAP NetWeaver 7.0: Stop all daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to stop process chains and real-time data acquisition.

SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

This has to be done after unlocking the RFC users but it should be done before restarting and enabling the other background jobs, e.g. by executing report BTCTRNS2.

Phase 6: Final Activities in Target Environment

Step 6.4: Delete source system assignments in the target BW after the copy
Directly after the copy, there is a connection from the target BW system (which still has the logical system name of the original BW system) to the source systems of the original BW system. Delete the source system connections in the target BW system without changing the source system connections in the original SAP source system.

In the target BW, change the contents of the "target host" field in all RFC destinations for SAP source systems to a non-existent address (transaction SM59). Caution: This step is very important, as otherwise the original source system will be changed!

Delete ALL SAP source systems in the RSA1 source system tree of the target BW system. Caution: This step deletes all transfer rules and PSA tables of these source systems, and the data is lost. A message is generated stating that the source system cannot be accessed (since you deleted the host of the RFC connection). Choose "Ignore".

Delete all obsolete RFC destinations pointing to the original environment.

Step 6.7: Rename the target BW system and convert the logical system names
If you want to rename the copied system, execute transaction BDLS. No other activities (for example, execution of Administrator Workbench / Data Warehousing Workbench (RSA1)) can be performed in the system during conversion!
Read Notes 121163 and 369758 for details about transaction BDLS.

Step 6.8: Perform BW-specific adaptations
Perform the following steps if the logical system name has been changed:

Reset generation flag for ODS activation programs. Call transaction RSSGPCLA and select program class RSDRO_ACTIVATE. Click #set status# and #OK#. Repeat for program class RSDRO_EXTRACT and RSDRO_UPDATE

Perform the following steps if the host has been changed:

Adjust the table RSLOGSYSDEST for the RFC destinations of the SAP source systems and the myself system. This table contains the relationship between the logical system names and RFC destinations.

If you are using BI Planning, adjust the server name of the BI Enqueue Server in the administration transaction RSPLSE. For details see Note 996238.

Reset RFC destination for process chain transport postprocessing. Use transaction RSTPRFC to correct the host.

If you are using a BW Accelerator, refer to SAP Note 1146983 for further instructions.

Step 6.16: Restart productive operation in the target BW system

SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

This has to be done after unlocking the RFC users and after configuring the number of background work processes.

=====================================================================
Scenario B3

You want to copy a single BW system of the group; the source system is not copied. You want to refresh an existing non-productive BW system by copying the source-system-independent objects from the productive BW system [PRD to NPS, refresh].

Remark: As a consultant, you may also read note 1333302, which describes a simplified copy scenario for special system landscapes.

Phase 2: Preparations in Target Environment

Step 2.1: Save source-system-dependent objects
Create a special transport with the source-system-dependent objects (transfer structures, InfoPackages, ...) in the transport connection of the target BW system to be overwritten (transport collector -> grouping: system copy) for each SAP source system. In the area "Source System Assignments", select the source systems for which you want to collect the source-system-dependent objects. Select all collected objects, even if some are not selected by default.

Caution: We recommend that you have a look at the object list of the transport to make sure that it contains all necessary objects. If this transport is inconsistent, the source-system-dependent objects are lost when the target BW system is overwritten. Do not forget to release the transport before the copy.

Remark: This transport request can also be created in the copied BW system after replacement by the productive BW (before step 6.4).
If the source system of the productive BW and the source system of the target BW deliver the very same datasources, this does not make a difference. However...
... if the source system of the target BW delivers additional datasources, the corresponding transformations would be lost.
... if the source system of the productive BW delivers additional datasources, this would lead to import errors later.

Step 2.3: Delete source-system-assignments in the target BW system before the copy
In the target BW system to be overwritten, delete all SAP source systems in the Administrator Workbench / Data Warehousing Workbench (RSA1). DO NOT delete the myself system!
This step is necessary to delete all source-system-dependent objects from the source system (the objects of the old source system connection would interfere with the new source system connection, which will be created after the copy).

Phase 3: Preparations in Source (Original) Environment

Step 3.3: Stop productive operation in the original BW system

SAP NetWeaver 7.0: Stop all daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to stop process chains and real-time data acquisition.

SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

This has to be done after unlocking the RFC users but it should be done before restarting and enabling the other background jobs, e.g. by executing report BTCTRNS2.

Phase 6: Final Activities in Target Environment

Step 6.4: Delete source system assignments in the target BW system after the copy
Directly after the copy, there is a connection from the target BW system(which still has the logical system name of the original BW system) to the source systems of the original BW system. Delete the source system connections in the target BW system without changing the source system connections in the original SAP source system.

In the target BW system, change the contents of the "target host" field in all RFC destinations for SAP source systems to a non-existent address (transaction SM59). Caution: This step is very important, as otherwise the original source system is changed!

Delete ALL SAP source systems in the RSA1 source system tree of the target BW system. Caution: This step deletes all transfer rules and PSA tables of these source systems, and the data is lost. A message is generated stating that the source system cannot be accessed (since you deleted the host of the RFC connection). Choose "Ignore".

Delete all obsolete RFC destinations pointing to the original environment.

Step 6.7: Rename the target BW system and convert the logical system names
Assign the name assigned to it before it was overwritten with the productive BW system (logical system name, table T000) to the target BW system. Use transaction BDLS to convert the logical system name in all the relevant tables. No other activities (for example, execution of Administrator Workbench / Data Warehousing Workbench (RSA1)) can be performed in the system during conversion!
Read Notes 121163 and 369758 for details about transaction BDLS.
Also execute the BDLS to map the old source systems of the productive environment (which you have deleted in step 6.4) to the new corresponding source systems of the quality environment which you are going to create in step 6.8

Step 6.8: Perform BW-specific adaptations
Connect the source systems that were connected to the target BW system before it was overwritten. Use the Administrator Workbench / Data Warehousing Workbench (RSA1), right mouse click on Source Systems and choose Create.

Perform the following steps if the logical system name has been changed:

Update logical system descriptions in RSA1. For each SAP source system that was converted using BDLS, change the description to match the new logical system name.

Reset generation flag for ODS activation programs. Call transaction RSSGPCLA and select program class RSDRO_ACTIVATE. Click #set status# and #OK#. Repeat for program class RSDRO_EXTRACT and RSDRO_UPDATE.

Perform the following steps if the host has been changed:

Adjust the table RSLOGSYSDEST for the RFC destinations of the SAP source systems and the myself system. This table contains the relationship between the logical system names and RFC destinations.

If you are using BI Planning, adjust the server name of the BI Enqueue Server in the administration transaction RSPLSE. For details see Note 996238.

Reset RFC destination for process chain transport postprocessing. Use transaction RSTPRFC to correct the host.

If you are using a BW Accelerator, refer to SAP Note 1146983 for further instructions.

Step 6.9: Import the transport with the source-system-dependent objects

First, adjust table RSLOGSYSMAP (This table is maintained in the target system of a transport and provides a mapping for the transport of source-system-dependent objects in BW systems. It maps the source system of the BW where the transport was created to the source system of the BW where the transport is to be imported. This means that it usually maps the source-system-dependent objects of source-DEV to source-TEST or source-PROD.). To enable the import of the source-system-dependent objects via safety-transport, this mapping has to be changed in the following way: source-TEST to source-TEST (If the transport was created in BW-TEST).
Import the transport request created before the system copy.
Change RSLOGSYSMAP back to the original mapping.

Execute programm RSBKDTP_BDLS to rename DTP-specific details. This has to be done after the transport with the source-system dependent objects has been implemented.

Step 6.16: Restart productive operation in the target BW system

SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

SAP NetWeaver 7.0: Stop all daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to stop process chains and real-time data acquisition.

SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

This has to be done after unlocking the RFC users but it should be done before restarting and enabling the other background jobs, e.g. by executing report BTCTRNS2.

Phase 6: Final Activities in Target Environment

Step 6.7: Rename the target client and convert the logical system names
Assign a new name to the target BW client (logical system name, table T000). Use transaction BDLS to convert the logical system name in all the relevant tables. No other activities (for example, execution of Administrator Workbench / Data Warehousing Workbench (RSA1)) can be performed in the system during conversion!

Ensure that you select the (non-default) option "Conversion of client-specific tables (e.g. after a client copy)" in transaction BDLS. You must not convert client-independent tables under any circumstances! If you cannot select this option, you are using an obsolete version of transaction BDLS. Get the latest patch for the transaction!

Read Notes 121163 and 369758 for details about transaction BDLS.

Step 6.8: Perform BW-specific adaptations
The newly created client is not a BW client, i.e it cannot be used to start the Administrator Workbench / DataWarehousing Workbench (RSA1) and load data. It is not connected to any BW source system and, as a result, no BW-specific activities are necessary in this step.

Step 6.16: Restart productive operation in the target BW system

SAP NetWeaver 7.0: Restart daemons for real-time data acquisition in transaction RSRDA.

SAP NetWeaver 7.2: Execute report RS_SYSTEM_SHUTDOWN to restart process chains and real-time data acquisition.

If the table is empty, you do not have to execute function module RSAP_BIW_DISCONNECT

If entries exist, note down these entries: fields RLOGSYS and SLOGSYS.

Execute function module RSAP_BIW_DISCONNECT in the copied target SAP source system using the following parameters:

I_BIW_LOGSYS = <RLOGSYS>

I_OLTP_LOGSYS = <SLOGSYS>

I_FORCE_DELETE = 'X'

If the table is empty, you do not have to execute function module RSAP_BIW_DISCONNECT.

If entries exist, note down all these entries: fields RLOGSYS and SLOGSYS.

Execute function module RSAP_BIW_DISCONNECT in the copied target SAP source system using the following parameters:

I_BIW_LOGSYS = <RLOGSYS>

I_OLTP_LOGSYS = <SLOGSYS>

I_FORCE_DELETE = 'X'

Check note 1810959 if you encounter problems with this step.
This step deletes all obsolete BW connections. Repeat this step for all entries in table RSBASIDOC.

Caution: DO NOT enter a value in the field "RFC target sys". This would cause the function module to run in the system specified there!

In the copied source system: Delete all obsolete RFC destinations pointing to the original environment.

Step 6.7: Rename the target SAP source system and convert the logical system names
Assign the name assigned to the overwritten SAP source system (logical system name, table T000) to the target SAP source system. Use transaction BDLS to convert the logical system name in all the relevant tables. No other activities can be performed in the system during conversion.
Read Notes 121163 and 369758 for details about transaction BDLS.

Step 6.8: Perform BW-specific adaptations
Restore the source system connection in the BW system connected to the overwritten SAP source system
Start the Administrator Workbench / Data Warehousing Workbench (RSA1), right mouse click on the source system, and choose Restore.

Repair the delta queue
In the BW system: Execute report RSSM_OLTP_INIT_DELTA_UPDATE for each datasource, which has an active init request. Provide the field 'ALWAYS' with value 'X'.
This will push the init / delta information of the BW into the source system, thus allows to continue loading delta or to do a new init.

=====================================================================
Scenario C4

You want to copy a single source system client of a BW system; the BW system is not copied. You want to create a new non-productive source system client (of an existing non-productive BW system) [PRD to NPS, installation, client] or refresh an existing source system client [PRD to NPS, refresh, client].

Phase 6: Final Activities in Target Environment

Step 6.7: Rename the target SAP source system and convert the logical system names
Assign the name assigned to the overwritten SAP source system client (logical system name, table T000) to the target SAP source system client. If the client created by the copy is a new client, choose a new name. Use transaction BDLS to convert the logical system name in all the relevant tables. No other activities can be performed in the system during conversion.

Ensure that you select the (non-default) option "Conversion of client-specific tables (e.g. after a client copy)" in transaction BDLS. You must not convert client-independent tables under any circumstances! If you cannot select this option, you are using an obsolete version of transaction BDLS. Get the current patch for the transaction!

Read Notes 121163 and 369758 for details about transaction BDLS.

Note: This copied source system client can be used and connected to BW system as a new BW source system (RSA1 -> SAP Source Systems -> Create...). Furthermore all source-system-dependent objects can be saved for each new SAP source system by creating the transport request (RSA1 -> Transport Connection -> Grouping -> Save for System Copy). In the area "Source System Assignments", select the source systems for which you want to collect the source-system-dependent objects. Select all collected objects, even if some are not selected by default.