Day: January 30, 2018

Overview:

* A business scenario in which IDoc is to be sent from SAP-ECC to Non-SAP System via SAP-PO (SAP Process Orchestration 7.5 Single Stack).
* Here, in this blog, we focus on how IDoc is been transferred from SAP-ECC to SAP-PO.
* In SAP-PO, IDoc-xml is to be transformed to a specific message format of Non-SAP System using Graphical Map and transformed message will be sent to Non-SAP System using SOAP Receiver Adapter communication channel, thus technically it can be called as a “Outbound IDoc-to-Soap Asynchronous Interface”.

Communication Channel Configuration:

IDoc is been transferred from SAP-ECC to SAP-PO using IDOC_AAE Sender Adapter, which can be configured in following manner:

1. RFC Server Parameters: Default(Recommended)

2. RFC Server Parameters: Manual

3. RFC Server Parameters: From NWA

Common errors during IDoc processing:

Normally in SAP-ECC’s t-code SM58, we see following common errors during outbound IDoc processing:

[1] Bean IDOC_INBOUND_ASYNCHRONOUS not found

[2] Error when opening an RFC connection (CPIC-CALL:

[3] Commit fault: ASJ.ejb.005043 (Failed in component: sap.com/com.sap.aii.ad

Resolution of above common errors:

* 3rd Error can be resolved by correcting/verifying following points:

* Check IDoc_AAE Sender channels started or not
* Also verify SAP-ECC’s t-code WE20 partner profile outbound parameter details

* 1st and 2nd errors can be resolved by correcting NWA Configirations for ‘Default’ settings as given below…..

NWA Configuration Steps for ‘Default’:

 [1]         In SAP-PO create a RFC Destination connecting to SAP-ECC

Create one RFC Destination named as  ‘XI_IDOC_DEFAULT_DESTINATION’

NWA url:       http://sappoHost:port/nwa

Path:             NWA -> Configuration -> Infrastructure -> Destinations -> Destinations

Enter SAP-ECC details like:

* Target Host                    eccHost
* System Number             eccSysNum
* System ID                      eccSystemID
* SAP Gateway Host        eccHost

* SAP Gateway Service   sapgwXX

* where XX is SAP-ECC’instance Number (generally value is 00)

[2]          In SAP-PO create a Program-ID for Sap-Ecc

Path: NWA -> Configuration -> Infrastructure -> JCO RFC Provider -> Create

Here again, we need to enter all following parameters related to SAP-ECC, for example:

* Program ID                     PgmID_Ecc_PO
* Gateway Host                 eccHost
* Gateway Service            sapgw00
* Server Count                  5
* Application Server Host  eccHost
* System Number              eccSysNum
* Client                               eccClient
* User                                 eccUserId 
* Password                         *****
* Language                        EN
*

[3]          In SAP-PO, Resource Adapter ‘inboundRA’ configuration

Path: NWA -> Configuration -> Infrastructure -> Application Resources -> filter ‘inboundRA’ -> select ‘inboundRA’ ‘Resource Adapter’ -> Tab ‘Properties’

In ‘Properties’ tab, maintain following settings:

* ProgramID                          PgmID_Ecc_PO
* MaxReaderThreadCount    5
* DestinationName                XI_IDOC_DEFAULT_DESTINATION
* GatewayServer                   eccHost
* GatewayService                  sapgw00
* Local                                   false
* BindingKey                          PI_AAE_IDOC

[4]          In SAP-PO, starting Java Applications for Resource Adapter ‘inboundRA’

Path: NWA -> Operations -> Systems -> Start & Stop -> Java Applications -> filter ‘inboundRA’ -> select ‘com.sap.aii.adapter.idoc.sapjra.inboundRA’ -> start

Once Java-Application ‘com.sap.aii.adapter.idoc.sapjra.inboundRA’ gets started, its status turns to green, and respective ‘inboundRA’ status also turns to green

[5]          In SAP-ECC, check Registered Program

Once Java-Application ‘com.sap.aii.adapter.idoc.sapjra.inboundRA’ gets started, at this event, program-id ‘PgmID_Ecc_PO’ gets registered in SAP-ECC

Registered programs in SAP-ECC can been seen via following steps:

* in t-code ‘SMGW’
* -> Menu item ‘Goto’ -> ‘Logged on Clients’
*
* Once window opens, check TP Name= program-id ‘PgmID_Ecc_PO’
* Here total 5 entries of TPName ‘PgmID_Ecc_PO’ can be seen, as maxThreadCount in ‘inboundRA’ is given as 5.
*

 [6]         In SAP-ECC, create a tRFC RFC Destination

Create one tRFC RFC Destination (t-code SM59) with following parameters:

* Registered Server Program        enabled
* Same program-id                        PgmID_Ecc_PO
* GatewayHost                              eccHost
* GatewayService                         sapgw00
* Unicode                                      enabled

Testing:

Once above configuration gets completed, to trigger IDoc from SAP-ECC to SAP-PO, we need to do following tasks:

* ALE-Configurations for outbound IDoc

* In SAP-ECC,

* t-code BD54:  maintain Logical Systems for SAP-ECC, SAP-PO
* t-code WE21: maintain tRfc PORT having tRFC destaination
* t-code WE20: maintain Partner profile for outbound IDoc
* t-code BD64:  maintain distribution model

* In SAP-PO,

* use import/use meta structure of IDoc in Enterprise Repository
* Configure scenario having IDoc_AAE Sender Channel with ‘Deafult(Recommended) settings’

* Trigger IDoc

  http://bit.ly/2EqfrLF #SAP #SAPCloud #AI

Hi All,

I am a newbie to SAP-HANA world and was recently exploring different types of CDS Views (particularly CDS Views with Input Parameters).

Though CDS Views with Input Parameters were introduced quite a long time back but I could not find a way to make some of the input parameters as Optional. So I played around with some annotations and found out a way to accomplish the same.

I did that with the help of annotation @Environment.systemField: #USER

I used the above annotation in my CDS View along with parameters in the following way: @AbapCatalog.sqlViewName: ‘Z_CDS_OP’ @AbapCatalog.compiler.compareFilter: true @AccessControl.authorizationCheck: #CHECK @EndUserText.label: ‘Material Query’ define view ZCDS_OP with parameters @Environment.systemField: #CLIENT p1 : mandt, @Environment.systemField: #USER p2 : uname, p3 : aenam as select from mara as ar { :p1 as Client, :p2 as Name, aenam as Created_By, matnr as Material } where ar.mandt = :p1 and ar.aenam = :p3;

Here the parameter p2 is defined for the sy-uname value, but it functions as an optional parameter at run-time.

If no value is passed for p2 parameter, the system defaults it to the sy-uname value.

Note that there is no asterisk (*) over p2 field. Below is the output of this query:

In this case my username is ‘FUNCTIONAL’ and is displayed in column ‘Name’.

Now I pass the value to the optional parameter:

Now, the p2 parameter value gets used and I get the following result:

This CDS view can also be consumed in an ABAP Program like the following: “Select Data from CDS view without optional parameter SELECT Client, Name, Created_By, Material FROM zcds_op( p3 = ‘FUNCTIONAL’ ) INTO TABLE @DATA(li_mara).

and "Select Data from CDS view with optional parameter SELECT Client, Name, Created_By, Material FROM zcds_op( p2 = ‘DEEPAK’, p3 = ‘FUNCTIONAL’ ) INTO TABLE @DATA(li_mara).

Both the code snippets work perfectly fine and generate the desired results.

So in this way I made a parameter optional in a CDS View. http://bit.ly/2EqBaDt #SAP #SAPCloud #AI

A common question that customers ask is whether or not their extensions will still work when they migrate from Design Studio 1.x to Lumira 2.x.  This is a fair question and our answer is usually nuanced.

Prior to 1.6, Design Studio used the SAP UI5 Commons library for rendering applications in the browser. In 1.6, we introduced optional support for the Fiori UX library, also known as SAP UI5 M.  I 2.x, we made Fiori the standard application rendering library and removed commons support. In the components SDK, we added a flag, allowing developers to declare whether their components were compatible with Commons only, M only, or both; via an xml attribute called “modes”.  Since Design Studio was Commons only prior to 1.6 and in 1.6, this was still the default (and most common) mode for applications, we included a clause that if this new metadata flag was missing, then Design Studio would presume that the component was commons only.  This clause was maintained in 2.x, even though Commons support was dropped.

There is something else. When designing a component, the developer can choose whether it is a native UI5 component, or whether they will start from scratch, with an empty div, and use their favorite javascript libraries. This is what my SDK tutorial does and is by far the most common approach for custom components. These components usually don’t care which version of UI5 is used, because they don’t use it. The most commonly seen native UI5 components are in the Community SDK Components.

There are a few possible ways that this can affect a component:

* The component has been created since 1.6 was released and was originally built to be compatible with both M and Commons. It works as is under 2.x.
* The component was created before 1.6, but is actively maintained and the creator has released an updated version, compatible with both M and Commons. It works as is under 2.x. E.g., there is a 2.0 version of the community SDK Components.
* The component was built for 1.6 and is compatible with Commons only and the developer made an explicit statement to this effect. This usually happens when the component is a native UI5 component and the developer only created a version for commons. You are out of luck, unless the developer updates it.
* The component was originally built with 1.5 or earlier and is a native UI5 component and never updated. This specific use case was the reason for the default modes was commons and is really the same as the scenario above.
* The component was created under 1.6 and is not a native UI5 component, but the developer explicitly declared modes as supporting Commons only. This should be very rare.
* The component is not a native UI5 component and was either created prior to 1.6, or the developer never bothered to make a modes declaration. In principle, most such components should not have a problem and can probably run under 2.x with only a metadata tweak; adding a modes declaration.

This last scenario is quite common and has caused some degree of pain in the customer community. Many older components that should have no problem running in 2.x can’t, simply because of a missing modes declaration.

The Lumira Extension Migrator

If your component extensions falls into the category of components which could theoretically be migrated without a rewrite, you have a couple of options. The absolute best approach, if you have access to the original eclipse project, is to tweak the modes attribute yourself in contribution.xml and create a new installer, taking care to test exhaustively. If you don’t have access to the original development project and only have the .zip installer file, you can use the Lumira Extension Migrator, an open source (Apache 2.0 license) migration utility.  This is not official SAP software, but rather an open source project that I wrote on my own to aid in migration.

The Lumira Extension Migrator is a utility which can do two things:

* It can analyze a Design Studio/Lumira Designer component extensions installer zip and report on which components are already 2.x compatible, which are not but can be migrated and which ones can’t be automatically migrated.
* It can create a copy of the installer .zip, modified to include the modes tweak on suitable components.

Getting the Lumira Extension Migrator

It is available here, on github. Clone it using git utilities, or manually download it. The utility itself is Migrate.py. You will need Python installed, in order to execute this utility.  It was written with Python 3, as Python 2.x is nearing its EOL date, so you need the latest version of Python 3.x to run it.

The extension migrator is a command line utility. Once you have it downloaded, open the command prompt migrate to its directory to execute it. To review the command line options, type to following command in: Python Migrate.py -h

Reporting with the Lumira Extension Migrator

Python Migrate.py –r

If executed with the –r (reporting) option, Migrate.py will survey the extensions installed into Designer and report on their status. This will help you plan your next steps.

Automated migration with the Lumira Extension Migrator

To migrate an installer, you need three command line parameters.

-f The folder path, where the file to be migrated is located.
-s The source file.
-t The target file.

For example, the Design Studio 1.4 SDK samples are not 2.x compatible, because the modes attribute did not exist then. Suppose I have an installer .zip, named DeployableSDKSamples14old.zip, in my Downloads folder.  Seven of the 18 components in the 1.4 samples are UI5 based and can’t be migrated. The other 11 can be and I want to make them 2.x compatible. I might do the following: Python Migrate.py -f “C:UsersdaveDownloads” -s “DeployableSDKSamples14old” -t “DeployableSDKSamples14”

You can explicitly write the .zip extension in the names, or leave it out. If it is left out, then it is implied. When executing the command, I’d see the following: Sparkline metadata modified to be Lumira 2.x compliant. Colored Box metadata modified to be Lumira 2.x compliant. Exception Icon metadata modified to be Lumira 2.x compliant. KPI Tile metadata modified to be Lumira 2.x compliant. Simple Crosstab metadata modified to be Lumira 2.x compliant. Video metadata modified to be Lumira 2.x compliant. Clock metadata modified to be Lumira 2.x compliant. Audio metadata modified to be Lumira 2.x compliant. Timer metadata modified to be Lumira 2.x compliant. Simple Table metadata modified to be Lumira 2.x compliant. Application Header is a UI5 component and can’t be automatically migrated. Left unchanged. Color Picker is a UI5 component and can’t be automatically migrated. Left unchanged. Formatted Text View is a UI5 component and can’t be automatically migrated. Left unchanged. Paginator is a UI5 component and can’t be automatically migrated. Left unchanged. Progress Indicator is a UI5 component and can’t be automatically migrated. Left unchanged. Rating Indicator is a UI5 component and can’t be automatically migrated. Left unchanged. Slider is a UI5 component and can’t be automatically migrated. Left unchanged. JSON Grabber metadata modified to be Lumira 2.x compliant. Migrated 11 components DeployableSDKSamples14.zip created in folder C:UsersdaveDownloads, with SAP UI5 modes commons and m. Uninstall the original from the Lumira Designer client and the BIP and install the updated version

Tips

Uninstall the originals, before installing the new versions.

Make sure you have a backup and don’t make the source and target filenames the same. This is why I named the 1.4 version DeployableSDKSamples14old.zip and the 2.x version DeployableSDKSamples14.zip, in the example above.

Test! Test! Test! This is a bling migration and should work for components that follow the developer guidelines, but test anyway. http://bit.ly/2nsjnDw #SAP #SAPCloud #AI