Here are simple steps to add extension fields to the header of standard BO and show those fields in a EC within a standard UI. I will use Service Request as an example

1. Create a XBO

[Extension] businessobject AP.CRM.Global:ServiceRequest {

        // You must activate this business object before you can access the extension fields

        // or messages in script files, forms, and screens.

                 //Scheduling time points

                 [Label(“Scheduled Start Time”)] [Tooltip(“Scheduled Start Time”)] element ScheduledStartTime : Time;

                 [Label(“Scheduled End Time”)] [Tooltip(“Scheduled End Time”)] element ScheduledEndTime : Time;

                 [Label(“Requested Start Time”)] [Tooltip(“Requested Start Time”)] element RequestedStartTime : Time;

                 [Label(“Requested End Time”)] [Tooltip(“Requested End Time”)] element RequestedEndTime : Time;

                 [Label(“Scheduled Start Date”)] [Tooltip(“Scheduled Start Date”)] element ScheduledStartDate : Date;

                 [Label(“Scheduled End Date”)] [Tooltip(“Scheduled End Date”)] element ScheduledEndDate : Date;

                 [Label(“Requested Start Date”)] [Tooltip(“Requested Start Date”)] element RequestedStartDate : Date;

                 [Label(“Requested End Date”)] [Tooltip(“Requested End Date”)] element RequestedEndDate : Date;

             

                 //Service location, default to US

                 [Label(“Country”)] [Tooltip(“Country”)] element CountryCode : CountryCode = “US”;

                 [Label(“House Number”)] [Tooltip(“House Number”)] element HouseNumber : LANGUAGEINDEPENDENT_EXTENDED_Text;

                 [Label(“Street”)] [Tooltip(“Street”)] element Street : LANGUAGEINDEPENDENT_EXTENDED_Text;

                 [Label(“Postal Code”)] [Tooltip(“Postal Code”)] element PostalCode : LANGUAGEINDEPENDENT_EXTENDED_Text;

                 [Label(“City”)] [Tooltip(“City”)] element City : LANGUAGEINDEPENDENT_EXTENDED_Text;

                  [Label(“State”)] [Tooltip(“State”)] element State : LANGUAGEINDEPENDENT_EXTENDED_Text;

                 node ServiceReferenceObject {

             }

  

}

2. Create an EC and bind it to the SR

Screen Shot 2013-12-10 at 11.43.17 PM.png

Screen Shot 2013-12-10 at 11.43.12 PM.png

3. Add a Data Field in the Data Model to hold the SR UUID. Don’t bind this field to anything. Example: SRUUID below.

Screen Shot 2013-12-10 at 11.19.13 PM.png

4. Add an Event that is a Read BO Operation and bind it to the SRUUID field you configured above. Example: EV_LOADSR

Screen Shot 2013-12-10 at 11.16.32 PM.png

5. Add an Inport and bind it to the SRUUID field you configured above. Also set the following properties: OnFire: EV_LOADSR, RequestAutoRefire: True, RequestFireOnInitial: True

Screen Shot 2013-12-10 at 11.49.30 PM.png

6. Add the EC with the Extensibility Explorer for the Service Request Agent Workspace Thing Inspector. Bind the TI Generic Outport ServiceRequest_UUID with the EC Inport

Screen Shot 2013-12-10 at 11.21.14 PM.png

Final Result

The Appointment and Service Location section groups are the XBO fields for the Service Request.

Screen Shot 2013-12-10 at 11.31.17 PM.png

Here is a working solution template example.

https://www.dropbox.com/s/scc1r5hwfj6am6p/YTEEM9L1Y_12-10-2013_115830_PM%28MRS%20Integration%29.zip

Thanks,

Rei

Rei Kasai

Product Management

SAP Cloud for Customer

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Stephen Johannes

    Why does this process look harder than on-premise SAP CRM using the AET?  Shouldn’t a cloud based solution be easier? This also looks very difficult compared to say adding new fields in another cloud based solution like ServiceNow which is very simple.

    What am I missing about your example that has reduced steps compared to on-premise SAP CRM or another SAAS solution like ServiceNow.

    Take care,

    Stephen

    (0) 
    1. Vinodkumar Kommineni

      Hi Stephen,

      Good to see you in this space 😎 !! I might be probably the guy to answer you on this as I have seen both the worlds.

      I feel AET is better than the KUT( Key user tool )/Adaptation we have here.

      The field added in this tool does not show up in the data model in the backend!! which is unlike on-premise probably due to multi tenant architecture.

      Secondly here we don’t have a configuration concept where you can hide fields from End users like they never existed by pushing to left.

      What you do from Adaptation is basically a kind of personalization for all users in system!!

      They would still be able to get them back from personalization…  every time I compare both solutions, this solution seems to be inferior, so I stopped it at one point and decided not to compare 🙂

      Regards

      Vinod

      (0) 
      1. Rei Kasai Post author

        I would like to comment that via business role configuration and access control lists (ACL) you can define down to the field level by role which fields are hidden, read-only, or full access. This will then allow key users via configuration to control who sees what, which means that if a certain user that has a role of hidden for a particular field for a BO, it will be hidden from the UI and then will not be able to add it via personalization.

        These are some of the large enterprise enhancements we are making for Cloud for Customer to make the platform very flexible.

        Screen Shot 2013-12-12 at 10.14.44 AM.png

        (0) 
        1. Vinodkumar Kommineni

          Hi Rei,

          Thanks for pointing it out, though I have seen this option it had slipped from my mind, but still when I compare both the products, cloud is having less configuration options compared to on-premise CRM where we have a far better control over the UI Configuration.

          Regards

          Vinod

          (0) 
      2. Stephen Johannes

        Actually I only showed up here because I have a list of all blogs, read those that might be interesting and comment on those where I have a point of view.  I have also been looking in more detail at various cloud based solutions, with a focus on sales/marketing.

        That’s interesting about the configuration limitations, I was expecting a little more power in the configuration design.  I was really expecting that cross-usage of fields would not be a consultant level concept.  I really don’t understand this fascination with fat clients for cloud solution configuration/development.  That being said I expect configuration tools for cloud solutions to better and more polished than on-premise stuff since remember cloud is supposed be more agile.

        I really was expecting a more service-now configuration model for screens and usage.  I can honestly say I had no formal training on service now and was able to extend tables with new fields and add those fields across multiple screens without ever opening a developer SDK.  They even had a way to transfer changes across your instances. To me having use an SDK to add fields so they can be used centrally in a cloud based system seems like a step backwards.

        That being said I really do appreciate the blog here and the further explanations.

        Take care,

        Stephen

        (0) 
  2. Rei Kasai Post author

    Great comment. The example above illustrates the steps you need to do if you want to use our Studio SDK to implement extension fields, package those fields into a common control (embedded component), and deploy that control in any screen. You can skip step 2-6 and add the fields directly into the standard UI if you don’t use the common control (embedded component approach).

    There is a more simple approach via Key User Extensibility which is similar to other cloud competitors, where via a web UI that the business users use, you can add the fields directly into the UI you are looking at.

    Adapting the User Interface – YouTube

    Screen Shot 2013-12-11 at 2.28.13 PM.png

    The advantage with the SDK approach is that you can easily package up these customizations into a template and then export/import them on any tenant, where as the Key User Extensibility approach is focused on making tenant specific changes very easily.

    So in the end it is a decision of the person making these customizations and their skillset. The SDK is meant for consultants and power admins, whereas the Key User Extensibility is meant for any business user.

    (0) 

Leave a Reply