Enhancements in Web Dynpro ABAP-Part II

In part I , we have seen about enhancing the view and window of the standard web Dynpro ABAP component, in this Part we will be seeing about Enhancement of controller and deleting an Enhancement.

Enhancement of controller:

Enhancement of controller consist of enhancements of Context Nodes, Attributes, methods and actions.

Context Node Enhancement:

Each controller will be having the context assigned to it, Context nodes/attributes can be enhanced or new nodes/Attributes can be assigned to the context.

There will be two kinds of nodes,

• Nodes without Dictionary structure mapping
• Nodes with Dictionary structure mapping

IF the node is without DD mapping then you can add the attributes to it by right click on it -> create – > attribute.

Before to this step enable the enhancement implementation.

IF the node is with DD mapping then you can add the attributes to it by right click on it -> create using wizard- > attributes from components of structure. 

Similarly you can add new nodes or attributes also to the same context by right click on the root context.

Attribute Enhancement:

To enhance the attributes tab go to the required controller, and enable the enhancement implementation.

Then the attributes tab will be enabled with Edit mode hence whatever the new additions are required or Existing attribute Edit( Except standard WD attribute) we can do here.

Enhancements of method and actions:

There will be two possible things we can do in methods, Enhancing the existing method or adding new method

First enable enhancement implementation for the methods tab.

Then the tab will be converted into Edit mode hence we can add new methods here like normal Edit.

Enhancement of the existing methods can be done in any of the following 3 ways.

• Pre Exit
• Post Exit
• Overwrite Exit

We are not going to change the code of the existing method, instead we will select the Exit option & a new method will be created there we can write our business logic’s.

Pre Exit:

This method will be called before the execution of actual method, this will be called by wd_this reference by the controller and later actual method will be called.

Post Exit:

This is just an opposite of Pre Exit, this method will be called after the execution of actual method with wd_this reference by the controller.

Overwrite Exit:

Overwrite method will replace the execution of actual method hence in this case actual method will not even get called.

Similarly if you wants to delete the newly created methods you can use the delete options which will be available just above to the methods.

Deleting Enhancement Implementation

To delete the Enhancement implementation, follow these steps

• Go to transaction SE80
• Select the package which you have saved the Enhancement object
• Select the implementation and delete it like it showed here.

Continue reading

MM-FI integration: Account determination simulator

MM-FI integration: A conceptual understanding

Now we know how MM and FI are integrated and how the account determination happens. If we want to test inventory account determination, neither you need to do actual material posting in the system nor go through master data and customization to identify the accounts. SAP has delivered account determination simulation tool.

This helps to find how an account is determined while posting stock related transactions. We just need to input plant, material, movement type and select the transaction we would like to check say GR for purchase order, GR for process order etc. Based on above inputs, system would read customization, master data and simulate the account determination process. Apart from above, system would also identify missing account assignments for a given transaction. This would further help to analyze issues in an easy manner.

Go to T-code OMWB and close the initial popup. Click on Simulation button.

Fill in plant, material , movement type and enter. Transaction list would be automatically refreshed based on the movement type. Double click on required type of transaction to be checked say GR and click on Account assignments.

In next screen, we can see the list of all available transactions possible for this movement type, plant and material combination. Some fields like material type, valuation class etc. are derived from material master data. Some fields like valuation area, valuation grouping code etc. are derived from customization of the plant.

In this screen, we can see what all accounts are determined for different kind of transactions.

EG: For Inventory posting, you can see Debit/Credit posting keys and respective G/L accounts. If there are any missing account assignment for a given transaction, this is also highlighted with text as “Missing”.

In above example, you can see this happened for Purchase account and purchase offsetting account. We don’t have any account assignments here as we are not using this scenario. By this way, we can clearly identify the gaps in account assignment without even doing the actual posting.

We can change to different movement types and transaction combinations and see how account determination happens and based on what fields it happens. You can try this in your system for various permutations and combinations.

Second feature available with this tool is, to check the MM-FI integration: Account determination simulator. This would help to identify any conflicts in screen layout rules for the inventory G/L account item during material document posting.

Screen layout for the inventory account item is determined at two levels.

1. From field status group of movement type

2. From field status group of inventory G/L account.

Click on “Check screen layout” button. In Next screen, we can see what is the field status set at movement type level and G/L account level. We should ensure that, there is no conflict between these two field status exist.

EG: We can’t have a field mandatory in one FSG and suppressed in other FSG. Posting would fail in such cases.

Sample output:

Just hover on the small ICON to see if a field is Mandatory/Optional/Suppressed/Display only. Any conflicts found should get reported in the error log in tool bar.

In case of conflicts, priority would be given in the sequence below with the exception of Required and suppressed combination which is not allowed.

1. Suppressed

2. Display

3. Required

4. Optional

Third option provided by this tool is, “where used list of G/Ls”. This would help to Identify in what all scenarios a G/L has been configured in the system.

From the main screen of OMWB, click on where used list of G/L.

Enter company code and valuation area in next screen and execute.

Sample output:

This output shows the list of valuation classes and transaction keys a G/L has been assigned to.

Hierarchy is as below.

Chart of accounts

                |-G/L account

                                |-Valuation class

                                                |-Transaction event key

                                                                |-Account grouping code

Continue reading

Automatic Account Determination

Inventory Management

Simply explanation: Managing the stock of material on qty and value basis is known as Inventory Management.

Whether Inventory is required or not for the material is controlled at material type and valuation area (plant) level.

In OMS2, Configuration required for each material type qty and value updating at valuation area level.

Case 1: If both Qty and Value update indicators are selected then PO can be raise for stock purpose and at GR material can be placed in store on qty basis and this Qty means stock value will be updated in inventory or stock G/L account.

Case 2: If qty update selected and value update not selected for material type at valuation area level, These material type related materials must procure for consumption Purpose. Means you should select account assignment category in PR and PO. At GR, received material is placed in store on qty basis but material value will be booked in relevant consumption G/L account but not in stock or inventory g/l account.

Inventory Management scenario’s can be defined as 1) Goods Receipt 2) Goods Issue 3) Stock Transfer 4)Transfer Posting

Characteristics of Goods Movements:

1) At least one material document will be generated and if goods movement is relevant to FI then accounting document to be generate.

2) Stock and Stock Value and Consumption Value may increase or decrease based on the goods movement.

3) If GR is entered against PO then PO history to be updated in Display PO.

4) Total value and Total stock, Moving average price to be updated (may be increase or decrease) in Material Master.

5) If Quality Management views are maintained with required fields, then when you completed the GR or GI, inspection lot to be generated when you run in QA32 , Based on Usage decision stock to be accepted or Rejected.

Sample process for Goods Receipt, Goods Issue, Stock Transfer, Transfer Posting.

Goods Receipts: 1) GR w.r.t Po for raw material

                               2) GR w.r.t Production order for finished Product.

                               3) GR With out for Production order

                               4) GR with out Purchase Order.

Goods Issue:      1) GI w.r.t Production order for raw material.

                              2) GI w.r.t sales order for finished product

                              3) GI to cost center or to plant maintenance.

                              4) GI to Scrap.

Stock Transfer:   1) Plant to plant stock transfer with in the company code.

                                2)From plant to plant across company code.

                                3)Store to Store stock transfer

Transfer Posting:  1) Unrestricted ⟺ QI ⟺ Blocked

Account Determination: (MM & FI Integration)

With this account determination Configuration settings,system will determine a suitable G/L account while posting GR (or) GI etc.

1) Account Determination with out wizard

I explained simply in one diagram, it is use full to remember the Process. Below I explained step by step.

1st Part:

Chart of account includes G/L accounts. This chart of account to be assigned to one company code or multiple company codes.

Note: Similar account determination required plants are grouped together and assigned to a valuation grouping code and then account determination will be configured at valuation grouping code level.

Step 1: Define Valuation Control (OMWM)

Here need to activate valuation grouping code.

For account determination, you can group together valuation area by activating the valuation grouping code.

Step 2: Group together valuation area.(OMWD)

here you assigned the valuation grouping code with combination of company code and chart of account and valuation area (plant) combination. If suppose similar account determination required plants are grouped together , here you can assign same valuation grouping code to multiple plants (or) multiple valuation areas.

2nd Part:

Material type and Account category reference and Valuation class.

Step 3: Define Valuation Classes.(OMSK)

In this step, you define which valuation classes are allowed for a material type.

So I am not going to this detailed. As account category reference is main controller and Mediator for material type and valuation class.

There is no direct configuration between material type and valuation class. Account category elaborates which material types related materials can be choose the which valuation classes.

You should enter this valuation class in material master.

3rd Part:

Step 4: Define Account Grouping for Movement types (OMWN)

Note: It is not possible to define new valuation string and new transaction event keys but account modifiers are editable with any movement type, for GBB or PRD or KON transaction keys are triggering then only account modifier also triggers.

Based on movement type system is triggering a valuation string and this valuation string is again triggers several transaction keys. but few transaction keys again triggers account modifiers or account grouping code also.

Below are the transaction event keys relevant account modifiers

GBB ⇨ BSA,INV,VBO,VBR,VNG,ZOB

PRD  ⇨ PRA,PRE,PRU

KON ⇨ PIP

Step 5: Configure Automatic Postings (OBYC)

In this step, you enter the system settings for inventory management and invoice verification transactions for automatic postings to G/L account.

Continue reading

Web Dynpro ALV Configurator

Messy code replaced by Config Step

Anybody who has developed applications using SAP WD ALV component SALV_WD_TABLE, know’s how many lines of code is required to configure ALV to specific requirements. There’s getting instance of ALV model and then calling all sort of API methods to fine tune standard ALV like- sequence the columns, hide, rename the column header, set lead selection behaviors, set column width, editable ALV or not, set cell editors and many more. For complex scenarios – set cell variant, map column properties with other field value(from context).

Now think of a solution which provides an ALV configurator which can be used to do all the above configurations so that developer doesn’t have to write that boilerplate code. The whole functionality is delegated to an external application. Your ALV instance automatically adjusts itself to the values set in the configurator.

Let’s say during UAT phase of your project – user wants to re-sequence the columns and also update column headings – you just have to make changes in the configurator. This can be done by functional consultant on the project – no developer involved – no source code change.

The architecture of this solution supports abstracting the common ALV functions like – showing record count, custom excel export, etc so that they can be easily provisioned.

Here’s the overview diagram of the solution.

Maintenance Cycle

1. Add ALV Usage to the business application
2. Add ZALV Usage for every ALV usage in the application
3. Execute the application once to update Z tables with original config values
4. Run the ZALV configurator app to override the original config values with wrapper values
5. Transport business application components and wrapper records to UT/IT/PD

Supported Features

• Almost all the ALV config properties mapped
• Supports all ALV column properties
• Supports screen resolution based adaptation ( details in next point )
• Supports config variants that can be selected based on qualifiers – eg – role name, screen size etc. So columns shown to ROLE_A can be different from ROLE_B. Similarly, more columns can be shown for higher resolution display.
• Supports overriding wrapper config value by run time value. Eg – retain the dynamic control of column visibility
• Custom ALV functions (ALV Buttons) can be built in ZALV component and provisioned to consumer apps
• ‘Record Count’, ‘Full Screen’  and ‘Custom Export’ functions are currently available

Design Consideration

• Non-invasive: Original component and its ALV config code is untouched
• Fallback: Just remove ZALV usage for easy fallback
• Usability
• Configurator lists the applications which uses ZALV with easy search mechanism.
• Drop Down selectors used for the properties. Value descriptions used instead of internal values.
• Property names are same as the one used in code for easy reference
• Z Tables
• Separate tables used for config, columns and functions.
• CONFIG_SOURCE field is used to easily identify source of config record
• CONFIG_SOURCE = 01 : Original Config
• CONFIG_SOURCE = 02 : Wrapper Config

With all said – the implementation is of proto-type (beta) quality and not any where near to production quality. I am making this open source on GITHUB so as to involve WD ABAP community to contribute, provide feedback/suggestions and use freely.

You can find more details in the github repository.

techaware/wdalv_config · GitHub

Continue reading

Connectivity News in AS ABAP 7.51

ABAP Channels

Multiplexer for WebSocket connections

In contrast to HTTP connection, which is short-lived and can be reused for multiple HTTP requests, the WebSocket connection is long-lived and cannot be reused for other WebSockets. That means that each WebSocket-enabled component requires its own WebSocket connection and the number of WebSockets connections grows over time. Besides this any web browser has its own WebSocket connections limitations and the ABAP application server might reach its connection limit as well.

To get over these problems you can now benefit from the multiplexer which virtualizes multiple WebSocket connections via the only one real WebSocket connection which is then used for exchanging messages. Each application (component) still establishes its own WebSocket connection but now this connection is virtual and doesn’t cause any physical load. Multiplexing is enabled by default for the WebSocket application in the AS ABAP via transaction SAPC and shipped on the client side with the PCP JavaScript library.

Enhanced support for large ABAP Channels messages

Now you can send large messages via ABAP Push Channel (APC) and ABAP Messaging Channel (AMC). The max. message length of messages for AMC was increased from 31 kB to approx. 1 MB and can be configured. The max. message length of messages for APC was increased from approx. 64 kB to approx. 100 MB and can be configured as well.

Create ABAP Push Channels applications in Eclipse

Now you can create ABAP Push Channels (APC) and specify APC applications (transaction SAPC) also in the ABAP Development Tools for Eclipse and so manage your APC applications without accessing a SAP GUI.

SAP Web Dispatcher / Internet Communication Manager

Network Edge Authentication

With Network Edge Authentication you get integrated, simple and secure Web access to backend systems of SAP solutions. SAP Web Dispatcher intercepts all incoming requests from the Internet and forwards only authenticated requests to backend systems in the internal network. Single sign-on and single log-off are provided for multiple independent backend systems including Fiori and SAP Enterprise Portal. A prerequisite for using Network Edge Authentication with SAP Web Dispatcher version 7.49 is a SAP Single Sign-On 3.0 SP1 installation. 

HTTP/2 Support

HTTP/2 (originally named HTTP/2.0) is a major revision of the HTTP protocol used by the World Wide Web.  HTTP/2 reuses the HTTP1.1 (methods, status codes, semantics etc.) but focuses on end-user perceived performance by optimizing network and server resource usage. Major goal is to use one single connection from browsers to a Web site.

The SAP ABAP application server as well as the SAP Web Dispatcher support HTTP/2 in the HTTP server role with release 7.51 and kernel version 7.49. The feature has to be enabled by setting the profile parameter icm/HTTP/support_http2=true. Please note: server push feature of HTTP/2 is not yet supported by the SAP ABAP application server.

RFC

RFC: New Fast Serialization

Now if you need a faster RFC connection, you benefit from new fast RFC serialization for RFC communication. The new fast RFC serialization is many times faster then xRFC/classic RFC or basXML, behaves uniformly for all data types and allowed extensions and is fully compatible with the existing RFC serialization types. You choose the fast RFC serialization in the transaction SM59 while defining RFC Destinations. It is only possible if both communication partners support the new serialization type. 

UCON: Managing HTTP(S) Whitelists

The UCON Framework offers you a new scenario within the transaction UCONCOCKPIT for whitelisting HTTP(S) calls based on a long-term logging. You can now maintain different whitelists for different context types. You are offered the comprehensive UI for all tasks and whitelists, where you can choose to maintain e.g. only one whitelist per context type and so that significantly reduce the number of whitelists. The number of context types itself was reduced from 10 to 3 by integrating similar context types into one new comprehensive context type.

Continue reading

Conditional Scheduling in SAP BI Web Intelligence

Unlike in Crystal Reports, In SAP Web Intelligence, it is not possible to schedule based on conditions.

However, often times you can accomplish this with the Publications as follows.

Introduction

In our sample, we will use the eFashion sample Universe / Database.

The sample business case is:

If Sales Revenue for a given City drops below certain threshold (2 Million USD), I want the board of directors to be informed via email and a personalized report to be sent to this group.
However, if the Sales for a City are more than 2 Million but lower than 3 Million I want the store manager to be informed.

We assume in this sample that you are familiar with both SAP BI Web Intelligence, and with SAP BI Publications.

Let us now see the steps in detail:

1. Create a Webi document that will be used to pre-process the Dynamic Recipients list.

Here you put only the basic stuff that is needed to build the list for the recipients.

In this sample, I entered in the report body the fields City and Sales Revenue.

Then I have created a Variable, type dimension, with the formula:
=If [Sales revenue] <3000000 Then “areamanager@mydomain.com”

ElseIf [Sales revenue] <5000000 Then “boardofdirectors@mydomain.com”

Else “”

Then I added this variable to the table.  This is what I got:

Then I filtered to remove the rows than do not need an alert (Right click, Filter, Add Filter, etc. as per below image)

This is the filtered output.

One last suggested set of steps is to:

– set the page margins to 0  and

– remove the report title

– align the table to the top left immediately under the report header.

We want to do this because otherwise when creating the Webi doc used for the Dynamic Recipients list you may have some issues when it tries to identify the column names.

Then save it to the Enterprise, and test it from BI Launchpad, you want to be sure that it works

2. Schedule to Excel the Document created at step 1.

This will create the data provider for the final Dynamic Recipient List source document.

This step is necessary, because the condition is based on a variable, and the Publications engine is not able to process variables within a Webi Document. This is the reason why we need to create this intermediate Excel Data Provider, so that we will have raw data and not variables.

To do so:

Logon to BI Launchpad, go to the folder where you saved the Webi Document that will be used to create the data provider for the  final Dynamic Recipient List source document.

• In the Recurrence, select Run Now. (Later you will re-schedule it and here you will enter the required settings.  Bear in mind that this must be refreshed before the publication will be sent.)
• In the Formats select the output format: Microsoft Excel
• In the Destinations section, enter: File System

If you have only one node, better to save on the server itself, otherwise it is preferable to save the output xls in a shared location. In either case, you need to be sure that the specified user name and password are correct and that account has r/w access to the folder you are scheduling the xls to.

Now save it to enterprise with a name like “Dynamic Recipients Final”, and once again, go to the BI Launchpad and test that the document can be refreshed without any issues.

3. Create the WebI Document to be used as Dynamic Recipients list for the Publication

In Web Intelligence, create a new WebI document, based on Excel Personal Data Provider.

The source file is the XLSX file created by the schedule at step 3.

This document will be practically identical to the one created at Step 1, the only difference is that the field with the email address is no longer a variable, hence this can be used as a Dynamic Recipients List.

Once created the document, save to enterprise with a recognizable name, i.e. “Dynamic Recipients Final”

4. Create the Publication

From the BI Launchpad, navigate to the folder where you will store the publication, right click and Select New > Publication.

In the General Properties, enter the Title,

in the Source Documents enter the Report you created at point #3

Now, from the left menu, select the Dynamic Recipients option, and specify the Source for Dynamic Recipients, then click on OK, after which you must select the Query and Map the fields.

You must also flag the checkbox “Use entire list”.

Next step is to configure the Personalization, which will be used to deliver the personalized reports to the users.

Last step is to complete the Destinations, see example in the image below.

You can also refine the publication advanced settings according to your requirements.

PS: It is not in the scope of this document to explain how Publications work, for more information please review the Business Intelligence Launch Pad User Guide.

Now you can test the publication, and adjust where necessary.

5. Fine tune the recurrence for the various schedules

Once you have successfully tested the various steps, it is time to adjust the recurrence of the various schedules, so that you have consistent results.

It is not in the scope of this document to go too much in depth into the details; however, it is suggested to put in place measures that prevent data inconsistency.

For example, the Publication should run after the Dynamic Recipients list has been refreshed, and before this can happen, the XLSX with the pre-processed recipients list must have been produced.

You can accomplish this with scheduling based on events, which is covered in the BI Launchpad User guide (7.1.8).

Continue reading

Account Category Reference (ACR) - Grandfather of Automatic Account Determination Process

Every movement of goods is followed by movement type only and without movement type use / without help of movement type – no goods movement is possible in SAP. During goods movement of transaction posting, movement type trigger transaction event key and G/L account assignment triggers based transaction event key (OBYC) with valuation class where valuation class determines the valuation class available in material master which is used for transaction posting. For automatic account determination, the vital direct parameters involves are  movement type, valuation class, chart of account, valuation area, business key (transaction key), valuation grouping code{ valuation modification or valuation modifier}, account grouping code{general modification or general modifier },nature of G/L account ,posting keys and value string.

Moderately understandable, only large vital factor – valuation class in material master determine G/L account on goods movement for a movement type and then, all are happy on validation in/for business process by cross checking accounting entries in each case/stage. Essential regard to account category reference (which is very much responsible of having valuation class in material master), play grandparent role by being silent friend for success to automatic account determination process.

The account category reference (ACR) is an artificial code of four characters which allows flexibility in linking material type with valuation class. In reality, the valuation class is linked to an account category reference and account category reference linked to material type. In other term account category reference is used to simplify the assignment of permitted valuation class/valuation classes to the material type/ material types.

Business Case-1: How to use Account Category Reference

Based on requirement, business can have one material type, one account category reference and one valuation class by assigning material type to account category reference and then assigning account category reference to valuation class. For example business can have one custom material type ZROM (Raw Material) with custom account category reference (Z001) and new valuation class (3005) for Raw Material(Raw material – inventory managed with quantity and value)

During material creation with transaction code: MM01 with certain material type manually or by any uploading tool, only one permitted valuation class is defaulted for that material type by account category reference. So in material creation process no chance of making any mistakes by users or by any uploading tool.

Business Case-2: How to use Account Category Reference

Based on requirement, business can have one material type, one account category reference and multiple valuation classes by assigning material type to account category reference and then assigning account category to valuation classes. For example business can have one custom material type ZROM (Raw Material) with custom account category reference (Z001) and new valuation classes i.e. (3005) for Raw Material, (3006) for Chemicals and (3007) for Filter material (all materials are inventory manage with quantity and value)

During material creation with transaction code: MM01 with certain material type manually or by any uploading tool, only permitted valuation classes are defaulted for that material type by account category reference . Here, there is a chance of entering wrong valuation class by user manually or through upload file using a tool which needs to be validated.

Business can go for designing a custom transaction code where material can be created through uploading file which can be verified by central material creation officer.

Business Case-3: How to use Account Category Reference

Based on requirement, business can have multiple material types, one account category reference and multiple valuation classes by assigning material types to account category reference and then assigning account category reference to valuation classes. For example business can have three custom material types such as  ZROM (Raw Material), ZCHE(Chemicals ) and ZFIL(Filter material ) with one custom account category reference (Z001) and three new valuation classes ie.. (3005) for Raw Material, (3006) for Chemicals and (3007) for Filter material (all materials are inventory manage with quantity and value)

During manual material creation with transaction code: MM01 or material creation by any uploading tool, only permitted valuation classes are defaulted for that material type by account category reference. Here, entering correct combination of material type for material and valuation class are expected through manually or through upload file which needs to be validated.

Business can go for designing a custom transaction code where material can be created by referring uploading file which can be verified by central material creation officer.

Also business can think of having “material master creation form” for any new material master creation, if necessary material code/ material number is not available in system – User/Users can fill the “template of uploading file’ with duly filled “material master creation form” and send for approval.On appropriate check and verification with approval from approving authority, if central material creation officer is happy, then he /she can upload file with custom transaction code for new material code.

Continue reading

Identify changed data on screen in Web dynpro ABAP

AT times we require to check whether the editable fields are actually changed in value by the user or not.AS we all know that the values in the web dynpro component are stored in the context via nodes and attributes, there is a way to acheive this without much of coding. This documents gives the step by step procedure for the same.

The component here has a node which in turn has an attribute associated with it.

The purpose of this attribute is to bind it with an input field, now we will create the layout after creating this node in the context.

The layout of view is as below

On the click of this button we will be checking whether user has entered something in the input field or not, this can be modified as a “SAVE” button on screen wherein we can now check whether user has actually entered something or not or user has actually entered a new value here or not.

For this We will Enable the context change log in the WDDOINIT of component controller, please note that since the node was created in the component controller we write the code in WDDOINIT of the component controller, in case this was declared in view the below code has to be written in WDDOINIT of the view.

create a method in component controller , here its named as “GET_CHANGE_LOG” and code as below. this method will be called from the view.

The table IT_LIST will have values when the field is changed from the previous value else that would be “INITIAL”.

Below are the test results:

Execute the application and press the button without entering any value

The internal table IT_LIST would be having no enteries.

Now enter some value in the input field and press the button

This time the internal table would have an entry as the context value was changed from previous held blank value

Continue reading