Parallel portal implementation in a non-unicode landscape

Hi All,
We have existing 3 system landscape with 3 systems in it.
DEVQASPRD.All of these systems are non-unicode.
The java add-in cannot be installed on them because the unicode java stack cannot talk to nonunicode abap stack.The customer does not wants to get his systems conerted to unicode.
So, how the portal implementation can be carried out in such a scenario?
We want to have an IPC installed  too.
Can the communication happen in the following manner.
PRD(non-unicode)--->ipc--->EP.
PRD writing the pricing configurations on the ipc database and EP picking up the data from ipc??
Regards,
Prasanna

Hello,
We have the ECC 6.0 abap only as the backend.
Can the internet pricing configurator of the ECC 6.0 stack (VMC IPC) communicate with the portal to extract the pricing?
Since SAP IPC comes as a part of kernel for abap basic 7.0 and is it necessary to install the standalone IPC for it communicate with the portal.
Regards.
Prasanna

Similar Messages

  • Portal Implementation with Unicode options on R/3 systems

    Dear All,
    I have a very specific and unique query. We are implementing ESS, MSS, MBO for our clients, and in the process have upgraded the production servers to R/3 4.7 version ( Non - Unicode ). We're using EP 6.0 as the front for the same .
    My question is as below :
    Today the client is not interested in having interface other than english, but moving down the line after 2 years he would like to have a Korean language interface, which might require R/3 4.7 with Koran language unicode and functions converted.
    What I want to know is whether this effort in upgrading to the unicode version of Korean on R/3 , before we actually implement ESS / MSS etc is better or should we upgrade to a unicode version 2 years later ?
    In either case what are the advantages and disadvantages ?
    Expert insight sought,
    Regards,
    Neeraj S.

    Hi Marcel,
    The portal capabilities of SAP NetWeaver are built on unicode (all JAVA based applications are based on unicode). This means that you can install many languages including exotic language like Kanji, Chinese, etc on the system.
    SAP R/3 Enterprise (4.7) supports 3 multi-language solutions:
    Unicode: Same as portal in that almost all language characters in the world are supported.
    Single non-unicode code page: Prior to unicode, single code pages enabled support of multiple languages with common characters via one code page (e.g. Latin-1 code page supported all western European languages).
    MDMP: a stop gap solution prior to the release of unicode which used a clever switching mechanism to handle the processing of languages that spanned multiple non-unicode code pages. This solution had very strict restrictions and is not recommended anymore as unicode is available. mySAP ERP 2005 does not support MDMP anymore.
    If you connect a portal to a backend mySAP ERP system you should only communicate and process languages that are installed on the mySAP ERP system. This ensures that no data is corrupted during transfer. Obviously the portal can support more language but you should not interface with the backend system in these languages.
    I hope this helps,
    Mike.

  • Unicode and Non-Unicode Instances in one Transport Landscape

    We have a 4.7 landscape that includes a shared global development system supporting two regional landscapes.  The shared global development system is used for all ABAP/Workbench activity and for global customization used by both regional production systems.  The two regional landscapes include primarily three instances - Regional Configuration, Quality Assurance, and Production.  The transport landscape includes all systems with transport routes for global and regional.
    A conversion to unicode is also being planned for the global development and one regional landscape.  It is possible that we will not convert the other regional landscape due to pending discussions on consolidation.  This means one of the regional landscapes will be receiving global transports from a unicode-based system.  
    All information I've located implies no actual technical constraints.  Make sure you have the right R3trans versions, don't use non-Latin_1 languages, etc.  Basic caveats for a heterogenous environment ....
    Is anyone currently supporting a complete, productive landscape that includes unicode and non-unicode systems?   If so, any issues or problems encountered with transports across the systems?  (insignificant or significant)
    Information on actual experiences will be greatly appreciated ....
    Many thanks in advance.

    Hi Laura,
    Although i do not have the live / practical experience, but this is what i can share.
    I have been working on a Non-Unicode to Unicode conversion project. While we were in the discussion phase there was one such possibility of a scenario that part of the landscapes would remain non-unicode. So based on the research i did by reading and directly interacting with some excellent SPA consultants, i came to know there are absolutely no issues in transporting ABAP programs from a Unicode system to non-unicode system. In a Unicode system the ABAP code has already been checked and rectified for higher syntax checks and these are downward compatible with the ABAP code on lower ABAP versions and non-unicode systems. Hence i beleive there should not be any issues, however as i mentioned this is not from practical experience.
    Thanks.
    Chetan

  • Open dataset in UTF8. Problems between Unicode and non Unicode

    Hello,
    I am currently testing the file transfer between unicode an non unicode systems.
    I transfered some japanese KNA1 data from non unicode system (Mandt,Name1, Name2,City) to a file with this option:
    set local language pi_langu.
      open dataset pe_file in text mode encoding utf-8 for output with byte-order mark.
    Now I want to read the file from a unicode system. The code looks like this:
    open dataset file in text mode encoding utf-8 for input skipping byte-order mark.
    The characters look fine but they are shifted. name1 is correct but now parts of the city characters are in name2....
    If I open the file in a non unicode system with the same coding the data is ok again!
    Is there a problem with spaces between unicode an non-unicode?!

    Hello again,
    after implementing and testing this method, we saw that the conversion is always taken place in the unicode system.
    For examble: we have a char(35) field in mdmp with several japanese signs..as soon as we transfer the data into the file and have a look at it the binary data the field is only 28 chars long. several spaces are missing...now if we open the file in our unicode system using the mentioned class the size is gaining to 35 characters
    on the other hand if we export data from unicode system using this method the size is shrinking from 35 chars to 28 so the mdmp system can interprete the data.
    as soon as all systems are on unicode this method is obselete/wrong because we don't want to cut off/add the spaces..it's not needed anymore..
    the better way would be to create a "real" UTF-8 file in our MDMP system. The question is, is there a method to add somehow the missing spaces in the mdmp system?
    so it works something like thtat:
          OPEN DATASET p_file FOR OUTPUT IN TEXT MODE ENCODING UTF-8 WITH BYTE-ORDER MARK.
    "MDMP (with ECC 6.0 by the way)
    if charsize = 1.
    *add missing spaces to the structure
    *transfer strucutre to file
    *UNICODE
    else.
    *just transfer struc to file -> no conversion needed anymore
    endif.
    I thought mybe somehow this could work with the class CL_ABAP_CONV_OUT_CE. But until now I had no luck...
    Normally I would think that if I'am creating a UTF-8 file this work is done automatically on the transfer command

  • Fonts for printing - unicode or non-unicode

    Hi, How could i find whether the fonts am using for scripts and smartforms are unicode compatible or not.
    Regards,
    Vijayalakshmi

    Hello Kyle,
    thank you very much.
    I have think that I can install the j2ee engine unicode or non unicode. And I can install SAP EP with unicode or non unicode.
    There is a cd from SAP its named "NON_Unicode_INST_Master_CD".
    In this cd it gives a path "IM08_SOLARIS_64/SAPINST/UNIX/SUNOS_64".
    And there is a sapinst. With this sapinst I can install a portal.
    Is this portal then a unicode installation, although it is placed on the "NON_Unicode_INST_Master_CD"?
    Regards,
    Werner

  • Unicode vs. Non-Unicode with MI

    Hi all,
    We are looking at doing an installation of MI. We are currently Non-Unicode on our ERP system, although a Unicode conversion project is not too far away.
    According to the document: "How To Design a SAP NetWeaver Based System Landscape" (NW 7.0, ver 1, March 2008) on pg 15, it says:
    "It is required that an MI system with AS ABAP has the same Unicode type as the MI back-end system: If your MI back-end system is a Unicode system, also install a Unicode MI system (that is, both AS ABAP and AS Java on Unicode); if your MI back-end system is non-Unicode, install an MI system with non-Unicode AS ABAP (that is, AS Java on Unicode and AS ABAP on non-Unicode).
    Recommendation
    For new installations, it is recommended to install a Unicode based system for all SAP applications and SAP NetWeaver deployments that require an AS ABAP usage type based system (AS JAVA is only available in Unicode). In future all new installations from SAP will be Unicode only."
    This is clearly conflicting...We are an English-only shop, we have a Unicode conversion imminent, and SAP's direction is clearly Unicode.
    Should we even consider a Non-Unicode install?
    Thanks,
    Troy

    Hi,
    install a unicode middleware system for the following reasons:
    - Soon the BE will be unicode enabled.
    - The MI client is anyway unicode enabled, this means the end users can enter unicode characters anyway. After Unicode conversion of the backend your MI server would be the only non unicode component.
    - having the mw as unicode does not harm, even if the BE is non unicode (apart from the bigger DB size due to the code page)
    Best Regards,THomas

  • Sending special characters to non-unicode non-sap system: user exit

    Hello All,
    We are sending data from a SAP unicode system to a non-sap non-unicode system via IDOC. The idoc is standard idoc GLMAST which contains gl account information.
    Some text fields contained in this idoc can contain special Polish characters. If they are sent unchanged to the non-unicode system, they give problems in the destination system.
    What we would like to do is to build a user exit to convert these special characters, for example : 'é' becomes 'e', ....
    We used enhancement object ALE00001, function EXIT_SAPLBD11_001 and implemented it, but it seems this exit is not called. Can this user exit be used for this functionality?
    We also tried to change in SM59 the type of system of the destination to non-unicode, so that SAP replaces those special characters by #. But, than the error 02. Codepage not found is given in the idoc. Note: the link to the external system is not set up yet, so no actual connection is possible. Is this why we receive this error, and will this functionality work in the end with a non-sap system?
    Thanks for helping.
    Kind Regards,
    Bart Pelsmaekers

    I faced this problem in many project i implement below logic.
      DATA: c_splchar(2) VALUE '90',
            c_defaultchar(1) type c VALUE '#'.
    You have to move one by one character to this function module
              CALL FUNCTION 'URL_ASCII_CODE_GET'
                   EXPORTING
                        trans_char = spl_char
                   IMPORTING
                        char_code  = spl_code.
    All non unicode(Better you check) are always greater than 90.
             if spl_code is gt c_splchar.
                move c_defaultchar to c_splchar.
             endif.       
    "Reward points if usefull"
    Thanks,
    Narayan

  • UTF-8 stored in VARCHAR2 on a non-Unicode DB

    Hi there,
    we have a company that implements storing Unicode data in Oracle in the following way:
    A plain VARCHAR2 on a non-Unicode DB (charset is actually WE8MSWIN1252) receives UTF-8 coded data.
    As client and server have the same setting for NLS_LANG, no conversion takes place, and the app will run fine.
    (in my eyes, a clean way to set this up would be utilizing NVARCHAR fields for this, but this is no option)
    But: how can I do query based on these columns without getting garbage for each non-ASCII character?
    I imagine setting up views for that purpose, but I need the syntax on how to re-interpret the UTF-8 data coming from a VARCHAR2 field.
    I tried the following:
    SELECT CONVERT(column, 'WE8MSWIN1252', 'AL32UTF8') FROM table where ...
    This will give me the right data on a client with cp 1252 set up, with the restriction to 8 bit output.
    Now I would like to have a Unicode-capable application like SQL*Developer to be fully capable of dealing with the Unicode data, but I guess, for that to work, I would need the DB to deliver a NVCHAR2 output from the above query?
    Any help and comments appreciated.
    Tom
    Message was edited by: snmdla

    we have a company that implements storing Unicode data in Oracle in the following way:
    No - they don't. They are NOT storing unicode data - they are storing individual one-byte characters and using that VARCHAR2 column as a BLOB. Ask them how, of if, they query the data.
    A plain VARCHAR2 on a non-Unicode DB (charset is actually WE8MSWIN1252) receives UTF-8 coded data.
    No - it doesn't. It receives a string of one byte characters in the WE8MSWIN1252 character set. It does not know, or care, what those one-byte characters represent. All you are doing is storing BINARY data in that VARCHAR2 column one byte at a time. When you query it you will get one or several bytes back - but since Oracle thinks it is really character data, when it is actually binary, you can only match it by matching those one-byte characters.
    I imagine setting up views for that purpose, but I need the syntax on how to re-interpret the UTF-8 data coming from a VARCHAR2 field.
    You don't have UTF-8 data - you have a BLOB that you need to convert to UTF-8 data. You can use the DBMS_LOB.CONVERTTOCLOB procedure to do the conversion and specify the character set to use. See the DBMD_LOB API
    http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_lob.htm#i1020356
    CONVERTTOCLOB Procedure
    This procedure takes a source BLOB instance, converts the binary data in the source instance to character data using the character set you specify, writes the character data to a destination CLOB or NCLOB instance, and returns the new offsets.
    See this AskTom article for further review
    http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3575852900346063772

  • Mixing Unicode with non-unicode

    Hi, Wwe have ECC 6.0 and BI 7.0 running on Windows 2003 and Oracle 10.2.0.4 all on non-unicode
    We are about to install another BI 7.0 landscape.
    If I install this new BI 7.0 on unicode, should I expect issues when communicating between systems such as BI loads?
    Thanks.

    BI-Java are in the works for 2009, so, I will need to convert my first BW instance to unicode... ouch, that part was not planned. so, I guess I will have a lot of work in 2009.
    Technically it might work with a non-Unicode backend but you never know...
    If your BI system is a single codepage system the UC conversion is not that big. The tools are meanwhile so good you shouldn´t have any big issues. Make sure you are on the latest BASIS support package, this will help a lot.
    so, I will install the new BI landscape using unicode, that will save me from converting this system later.
    yes - definitely.
    And if the connected ERP (or CRM or whatever) backend is only single codepaged there won´t be any problems when you exchange data.
    Markus

  • Unicode and non-unicode

    WHAT IS DIFFRENTS BETWEEN UNICODE AND NON UNICODE ?
    BRIEFLY EXPLAIN ABOUT UNICODE?
                                                            THANKS IN ADVANCES

    A 16-bit character encoding scheme allowing characters from Western European, Eastern European, Cyrillic, Greek, Arabic, Hebrew, Chinese, Japanese, Korean, Thai, Urdu, Hindi and all other major world languages, living and dead, to be encoded in a single character set. The Unicode specification also includes standard compression schemes and a wide range of typesetting information required for worldwide locale support. Symbian OS fully implements Unicode. A 16-bit code to represent the characters used in most of the world's scripts. UTF-8 is an alternative encoding in which one or more 8-bit bytes represents each Unicode character. A 16-bit character set defined by ISO 10646. A code similar to ASCII, used for representing commonly used symbols in a digital form. Unlike ASCII, however, Unicode uses a 16-bit dataspace, and so can support a wide variety of non-Roman alphabets including Cyrillic, Han Chinese, Japanese, Arabic, Korean, Bengali, and so on. Supporting common non-Roman alphabets is of interest to community networks, which may want to promote multicultural aspects of their systems.
    ABAP Development under Unicode
    Prior to Unicode the length of a character was exactly one byte, allowing implicit typecasts or memory-layout oriented programming. With Unicode this situation has changed: One character is no longer one byte, so that additional specifications have to be added to define the unit of measure for implicit or explicit references to (the length of) characters.
    Character-like data in ABAP are always represented with the UTF-16 - standard (also used in Java or other development tools like Microsoft's Visual Basic); but this format is not related to the encoding of the underlying database.
    A Unicode-enabled ABAP program (UP) is a program in which all Unicode checks are effective. Such a program returns the same results in a non-Unicode system (NUS) as in a Unicode system (US). In order to perform the relevant syntax checks, you must activate the Unicode flag in the screens of the program and class attributes.
    In a US, you can only execute programs for which the Unicode flag is set. In future, the Unicode flag must be set for all SAP programs to enable them to run on a US. If the Unicode flag is set for a program, the syntax is checked and the program executed according to the rules described in this document, regardless of whether the system is a US or a NUS. From now on, the Unicode flag must be set for all new programs and classes that are created.
    If the Unicode flag is not set, a program can only be executed in an NUS. The syntactical and semantic changes described below do not apply to such programs. However, you can use all language extensions that have been introduced in the process of the conversion to Unicode.
    As a result of the modifications and restrictions associated with the Unicode flag, programs are executed in both Unicode and non-Unicode systems with the same semantics to a large degree. In rare cases, however, differences may occur. Programs that are designed to run on both systems therefore need to be tested on both platforms.
    Refer to the below related threads
    Re: Why the select doesn't run?
    what is unicode
    unicode
    unicode
    Regards,
    Santosh

  • New Portal Implementation Questions?

    Hi,
    We've just started a Portal Implementation in our company. Our environment is as follow:
    - EP 6.0 SP9 (NW04 SR1 version)
    - SAP 4.6C System (WPPI installed)
    - Lotus Notes/Domino (we are using Domino LDAP)
    My Questions are as follow:
    1. Can we integrate Domino LDAP with portal? If not how can we access domino user database in this environment?Because all company users exist in domino database but small subset of company users have SAP user.
    2. Currently I've created a system for 46C r3 system in system landscape and set it to use UIDPW for user management. I've mapped one of portal user with a SAP user and created iviews to run with wingui and webgui. All worked successfully. My question is that if there is any wey to enable SAP users to logon Portal without mapping? Online Docs. says that it is not possible to use R3 systems other than based on 620 WAS as a datasource for UME.
    Regards

    Hi Huseyin,
    You need to create system in EP.
    System administration>System Configuration>system landscape-->
    1) create one folder like "system"
    2) create system in the above folder
    3) Enter all the details of R/3 System
    4) create Iview and link to the R/3 system
    you could allways look at the manual:
    http://help.sap.com/saphelp_nw04/helpdata/en/0d/17df3d2cae445ae10000000a11405a/frameset.htm
    hope it helps,
    Yoav

  • Regarding Conversion Of ABAP program from non unicode to uni code

    Hi Can you please let me know the procedure for converssion of non unicode to unicode?
    Thanks in advance,
    zubera

    Hi
    The Link will be helpful to you.
    Re: Upgrade 4.6 to ECC - What are the responsibilites
    regarding Unicode influence in Standard programs
    Very good document:
    http://www.doag.org/pub/docs/sig/sap/2004-03/Buhlinger_Maxi_Version.pdf
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d37d1ad9-0b01-0010-ed9f-bc3222312dd8
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/589d18d9-0b01-0010-ac8a-8a22852061a2
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f8e316d9-0b01-0010-8e95-829a58c1511a
    You need to use the transaction UCCHECK.
    The report documentation is here
    ABAP Unicode Scan Tool UCCHECK
    You can use transaction UCCHECK to examine a Unicode program set for syntax errors without having to set the program attribute "Unicode checks active" for every individual program. From the list of Unicode syntax errors, you can go directly to the affected programs and remove the errors. It is also possible to automatically create transport requests and set the Unicode program attribute for a program set.
    Some application-specific checks, which draw your attention to program points that are not Unicode-compatible, are also integrated.
    Selection of Objects:
    The program objects can be selected according to object name, object type, author (TADIR), package, and original system. For the Unicode syntax check, only object types for which an independent syntax check can be carried out are appropriate. The following object types are possibilities:
    PROG Report
    CLAS Class
    FUGR Function groups
    FUGX Function group (with customer include, customer area)
    FUGS Function group (with customer include, SAP area)
    LDBA Logical Database
    CNTX Context
    TYPE Type pool
    INTF Interface
    Only Examine Programs with Non-Activated Unicode Flag
    By default, the system only displays program objects that have not yet set the Unicode attribute. If you want to use UCCHECK to process program objects that have already set the attribute, you can deactivate this option.
    Only Objects with TADIR Entry
    By default, the system only displays program objects with a TADIR entry. If you want to examine programs that don't have a TADIR entry, for example locally generated programs without a package, you can deactivate this option.
    Exclude Packages $*
    By default, the system does not display program objects that are in a local, non-transportable package. If you want to examine programs that are in such a package, you can deactivate this option.
    Display Modified SAP Programs Also
    By default, SAP programs are not checked in customer systems. If you also want to check SAP programs that were modified in a customer system (see transaction SE95), you can activate this option.
    Maximum Number of Programs:
    To avoid timeouts or unexpectedly long waiting times, the maximum number of program objects is preset to 50. If you want to examine more objects, you must increase the maximum number or run a SAMT scan (general program set processing). The latter also has the advantage that the data is stored persistently. Proceed as follows:
    - Call transaction SAMT
    - Create task with program RSUNISCAN_FINAL, subroutine SAMT_SEARCH
    For further information refer to documentation for transaction SAMT.
    Displaying Points that Cannot Be Analyzed Statically
    If you choose this option, you get an overview of the program points, where a static check for Unicode syntax errors is not possible. This can be the case if, for example, parameters or field symbols are not typed or you are accessing a field or structure with variable length/offset. At these points the system only tests at runtime whether the code is sufficient for the stricter Unicode tests. If possible, you should assign types to the variables used, otherwise you must check runtime behavior after the Unicode attribute has been set.
    To be able to differentiate between your own and foreign code (for example when using standard includes or generated includes), there is a selection option for the includes to be displayed. By default, the system excludes the standard includes of the view maintenance LSVIM* from the display, because they cause a large number of messages that are not relevant for the Unicode conversion. It is recommended that you also exclude the generated function group-specific includes of the view maintenance (usually L<function group name>F00 and L<function group name>I00) from the display.
    Similarly to the process in the extended syntax check, you can hide the warning using the pseudo comment ("#EC *).
    Applikation-Specific Checks
    These checks indicate program points that represent a public interface but are not Unicode-compatible. Under Unicode, the corresponding interfaces change according to the referenced documentation and must be adapted appropriately.
    View Maintenance
    Parts of the view maintenance generated in older releases are not Unicode-compatible. The relevant parts can be regenerated with a service report.
    UPLOAD/DOWNLOAD
    The function modules UPLOAD, DOWNLOAD or WS_UPLOAD and WS_DOWNLOAD are obsolete and cannot run under Unicode. Refer to the documentation for these modules to find out which routines serve as replacements.
    Regards
    Anji

  • CRM unicode and ECC 6.0 Non unicode.

    Hi All,
    We have upgraded our system from 4.6C to ECC 6.0
    Our ECC 6.0 is non unicode system. We are currently implementing CRM 5.0.
    I want to know if we implement unicode CRM system, will there be any inconsistency as our ECC 6.0 is non unicode.
    Regards,
    Imran

    Hi Imran:
    I had a problem with middleware when going through a similar scenario to yours. The middleware functions were returning garbage when calling from CRM to ERP systems. See note 651497 which addresses this problem.
    I implemented the fix by adding the following line to the beginning of function module BAPI_CRM_SAVE:
    call function 'Z_MW_RFC_PING'.
    Create a function group containing function module Z_MW_RFC_PING (code below):
    FUNCTION Z_MW_RFC_PING .
    *"*"Local Interface:
    data:
      lv_rfcdest type rfcdest.
    * Read middleware parameter table to determine R/3 backend system
    * name.
      select single parval1
        into (lv_rfcdest)
        from smofparsfa
        where parsfakey eq 'CRMCFSOLTP' and
              parname eq 'CRMCFSOLTP'.
    * If we get an RFC destination returned, PING it.
      if sy-subrc eq 0.
        call function 'RFC_PING'
          destination lv_rfcdest.
      endif.
    ENDFUNCTION.
    Note 777994 addresses some configuration on CRM system. In transaction R3AC6 on CRM system, make the following entries:
    Key SMOF, parameter CODEPAGE_CHECK_OFF, value 'X';
    Key R3A_COMMON, parameter CRM_SEND_XML, value 'X';
    Key R3A_COMMON, parameter DATA_FORMAT, value 'XML'.
    You should also do the following configuration:
    In table CRMPAROLTP on ERP system set parameter CRM_SEND_XML_FOR_DEFAULT_DESTINATION, user CRM, value 'X'.
    In table CRMRFCPAR on ERP system set the "Use XML" flag to 'X' for the CRM consumer. This also avoids code-page issues.
    The above took care of conflicts in code-pages for my systems.
    Regards,
    D.

  • Problem: Establishing SSO between EP7.0(UC)  to SRM 4.0(non unicode)

    Dear gurus
    While creating SSO between EP 7.0 and SRM 4.0(non Unicode)....while uploading the certificate with  SSO2 tool from portal....by selecting add trusted system, The system throwing error message like:
    Error occurred: Selected system does not have SSO Model deployed.
    is there any restrictions are there for unicode system to Non system...Actually by using my EP system i am able to connect the BI7.0 system very well, where i am getting the erro with SRM 4.0 system only
    any help please
    Thanks in advance

    No, there are no such restrictions for SAP Logon Tickets / Assertion Tickets and Unicode vs. Non-Unicode systems.
    If you are using the [NWA Trust Configuration Wizard|https://service.sap.com/sap/support/notes/1083421] then it might happen that the [ABAP backend system does not provide the required APIs|https://service.sap.com/sap/support/notes/1014077]. In that case you have to setup the SSO2 trust relationship manually (using ABAP transaction STRUSTSSO2).

  • Non-unicode to unicode conversion

    Dear All,
         We have non unciode systems in our landscape and we planned to do unicode conversion. I would like to know the support period for non unicode system by SAP. Does anyone knows about When will SAP drops their support for non unciode? , so that we will plan for unicode conversion accordingly. Any links ro refer ? Thanks in advance.
    Regards
    Raj

    Hi Raj,
    1) as you can see from the link above, all new installations based on Netweaver 7.0 are supported as Unicode systems only.
    2) There is an FAQ about this statement: Please have a look at
    http://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000380759&_OBJECT=011000358700000045082008E
    3) The usage of new technologies like JAVA integration and eSOA applications are only supported on Unicode systems. Please have a look at SAP notes 838402, 975768 and 1358929.
    4) From my point of view, there is a high probability that the successing release of SAP Business Suite 7.0 will be Unicode only. However at the moment this is being discussed inside SAP and there is no outcome yet.
    Best regards,
    Nils Buerckel
    Solution Management
    Globalization Services
    SAP AG

Maybe you are looking for