jQueryMobile crew introduced as of vesion 1.3.1 some new cool Widgets / UI elements. One of those is Table: Column Toggle.
The column toggle table mode selectively hides columns at narrower widths as a sensible default but also offers a menu to let users manually control which columns they want to see.
One of our clients requested to use this new widget, within an WebApp that we have build, but with several adons. One of those adons was using checkboxes in Table.
They wanted to be able to select and deselect all checkboxes but also one by one. In this blog I will explain how to achieve this.
Create one empty page HTMl file using latest version of jQueryMobile. At the moment this is 1.3.2
Add table widget to the content DIV. Use the number of columns and rows as you wish. In our example we are using 3 rows and 5 columns.
Save the file and run. We have been able to use the advantages of Table: Column Toggle. A user may choose to check as many columns as they want by tapping the "Columns to display" button to open the column chooser popup.
The popup contains a dynamically generated list of columns based on the table markup that can be checked and unchecked to adjust the visible columns.
Now add checkboxes to column one and expand the widget by adding a class to all rows of the table by adding this code. Please check the ID of checkbox and
atribute "selected_row" of class="select_chkbx_table", they are the same!! We need ID to select or deselect the checkbox and atribute "selected_row" to check selected row.
Let's program some jQuery code. Add on click event to get selected row and then select the checkbox with the same ID.
Ok, so far so good. Now we are going to add buttons for selecting and deselecting all checkboxes.
Add jQuery code to do the real job of selecting an deselecting!
Let's add another button to call some event for getting all selected checkboxes.
Step 9 LIVE DEMO:
We are finished. You can see the demo here: Table: Column Toggle with checkbox - jQueryMobileLees meer >
Instead of having users to choose from a list of responsible service teams, you want to dispatch a servicerequest to a dedicated service team based on the chosen category. This functionality is delivered by SAP CRM using the Dispatch Functionality. Next to routing of the servicerequest, you can also execute other actions, like increasing the priority.
This document helps you to get this up & running.
Transaction types have to be assigned to a service manager profile that contains rule logic for the routing. Such service manager profile is available in standard customizing. This profile has an attribute ‘Policy’. The name of the policy must match the rule policy that is maintained in the IC_MANAGER role in the WebUI.
Step 1: Category Model
In the WebUI (role IC_MANAGER): Knowledge Management > Categorization Schemas. The Categorization Schema you use for your categorization, has to be assigned to the rule modeler application area:
Make sure you have assign Application ID ‘Rule Modeler’.
Step 2: ServiceManager Profile
This step is optional. See comments at the end of this step.
In SPRO: CRM > IC WebClient > Additional functions > Intent-Driven Interactions > Service Manager > Define Service Manager profiles.
Make a copy of profile SAP_SRQMROUTING to ZSAP_SRQMROUTING.
In this profile, go to Directly Called Services, Properties. Assign this profile to a new policy.
We call this policy ZTEST.
In stead of making a copy and adding the policy ZTEST, you can decide to use the standard profile which has policy DEFAULT_ROUTE. If you stay with the default settings, in the next steps, also use the default names in stead of the values we just defined.
Step 3: Assign profile to transaction type
SPRO: CRM > Transactions > Additional settings > Assign dispatching rule profile to transaction type.
Step 4: Rule Editor
In the WebUI (role IC_MANAGER): Process Modeling > Rule Policies: create a new rule policy for the service request context. Use the name of the policy you has chosen in step 3.
Add a new rule to the policy. We call it ‘TRIAL’. Add a condition (filter) and one or more actions.
This rule says:
(Condition:) if transaction type = ZZR1 (not visible in screen print) and category contains Code 1,
(action 1) assign Organizational Unit 50000164 to the service request and
(action 2) set priority to 1 (very high) and
(action 3) assign partner “user” as partner function 00000014 (employee responsible).
Step 5: Test
When updating the service request, select the category you have used in the rule modeller, so the condition gets fulfilled. Then, in the toolbar, select [More] à [Dispatch]. Now the rule will be executed.
All three actions will be executed. Result of action 1 and 3:
where your organisation will be 50000164 in our example.
You can use action DISPATCH to trigger the dispatch automatically. (BADI implementation CRM_SRQM_DISPATCH)Lees meer >
In stead of calling ‘just a website’, we want to call a website or webapplication to get detailed information, like ‘show me the hotels near this customer’.
This document describes options of defining solutions based on URL transaction launchers.
Transaction launchers have some inconvenient characteristics. A well known issue is when the link towards the transaction launchers is hit, the transaction launcher restarts every time and you lose the previous content (unless a new window is opened every time). Another problem can be, that the application inside the transaction launcher does not communicate back to CRM.
So you have been warned. But still ‘simple’ transaction launchers can be sufficient for your needs. Certainly, when we can make them more dynamic.
To embed a website in CRM that calls a specific URL is easy. In CRM customizing you create a URL definition and subsequently you generate a transaction launcher, that is to be embedded in the navigation profile and business role.
But now we want to call a more specific URL. We want to get only specific details, using attributes of a businesspartner for example, like country and city. We have two options:
- Build the URL dynamically, for example http://www.hotels.nl/nl/almere/ that has basic url http://www.hotels.nl followed by 'nl' as country and 'almere' as city.
- Call the URL with parameters, for example http://www.vvv.nl/modules/zoekvvv/zoek-een-vvv.aspx?bestemming=almere having ‘bestemming’ as parameter and ‘almere’ as value of this parameter (the part behind the question mark is all about parameters).
So it depends on the site that we need to call, which option is to be developed.
How to develop A
We need to do a little bit ABAP-coding for this option.
First we define a URL definition for the main site http://www.hotels.nl via tx. CRMC_IC_LTX_URLS.
Do not set any parameters.
Then we generate a transaction launcher for the URL definition using the wizard via tx. CRMC_UI_ACTIONWZ.
(we don’t need to send any parameter towards the transaction launcher)
In the generated transaction launcher class, we need to change some coding via tx. SE24.
But first we do the customizing part to add the transaction launcher to a business role in the WebUI.
First create a logical link:
Then add the link into a workcenter (it is also possible to add the link in a workcenter group or as direct link).
Then add the workcenter to a navigation profile.
By default a new workcenter is always visible. If you did not add the logical link into a new workcenter, set the link to visible in the business role.
DATA: lr_gdc TYPE REF TO if_crm_ui_data_context,
lt_entities TYPE crmtt_ui_data_context,
ls_entity TYPE crmt_ui_data_context,
lr_bupa TYPE REF TO cl_crm_bol_entity,
lr_entity TYPE REF TO cl_crm_bol_entity,
lv_city TYPE string,
lv_country TYPE string.
CALL METHOD super->build_other_url
rv_result = rv_result.
* we read data from the clipboard
lr_gdc ?= cl_crm_ui_data_context_srv=>get_instance( gv_view_controller ).
lt_entities = lr_gdc->get_entities( ).
* we get more attributes of the businesspartner.
READ TABLE lt_entities INTO ls_entity WITH KEY name = 'CURRENTCUSTOMER'.
lr_bupa ?= ls_entity-value.
IF lr_bupa IS BOUND.
lr_entity = lr_bupa->get_related_entity( iv_relation_name = 'BuilStandardAddressRel' ).
lv_city = lr_entity->get_property_as_string( iv_attr_name = 'CITY' ).
lv_country = lr_entity->get_property_as_string( iv_attr_name = 'COUNTRY' ).
* we build the final URL
IF lv_country IS NOT INITIAL AND lv_city IS NOT INITIAL.
CONCATENATE rv_result lv_country lv_city INTO rv_result SEPARATED BY '/'.
Comments to the coding:
Next to CURRENTCUSTOMER there are more objects in the context that you can use.
Like with every transaction launcher that is generated, do not forget to move the ABAP-class that is generated from the local development package $TMP to a transportable package if you need to transport your stuff towards a test/production system.
How to develop B
We do not need any manual coding for this option. (it’s all generated for us in the background).
Basically we prepare the same customizing steps, but we will use parameters in the URL definition and we assign them in the transaction launcher wizard.
When defining the URL definition, also set parameters. The site that we want to call, has predefined input fields. We can see them when we look at the HTML source code of the site. We see that this website is has input field ‘bestemming’, but also ‘type’ and ‘afstand’.
We define the (input) parameters:
In the transaction launcher wizard, we have to set mapping for the input parameters.
At the input parameter step, select every parameter and set a fixed value of assign a path using the clipboard context.
Overview of the 3 parameters that have been set:
Define a logical link and workcenter as described at A, and add the workcenter to a navigation profile.
Lees meer >