Recently, I received a question from an E-Sourcing professional asking about calling a Web Service from an E-Sourcing script. This is absolutely something that can be achieved quite easily; and, in fact, it is something that I have done for customers in the past.

As with any use of Web Services, however, you should carefully consider the security issues that may come up. How, for example, will the Web Service server validate that the Web Service client (E-Sourcing) is properly authenticated? Will password information be included in the web service call? You will find that it is very easy to make a web service call, but I would encourage you to carefully consider security before implementing a productive solution.

Web service calls can be made using raw Java web service APIs from the open source Axis library which is included with E-Sourcing; this approach is slightly more difficult to code, but very dynamic. Web service calls can also be made using proxies. In one solution that I worked on, we generated java proxies for the web service, compiled those proxies into a Jar file, and included that jar file as a custom jar in E-Sourcing. Let me provide a few more details on each of these approaches.

Using raw java web service APIs that are part of the Service and Call classes, I prototyped a web service call to Googles sample spell checker web service. Here is the code:

import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
import org.apache.axis.encoding.XMLType;
import javax.xml.rpc.ParameterMode;
import javax.xml.namespace.QName;

String endpoint = “http://api.google.com/search/beta2“;
Service  service = new Service();        
Call call = (Call) service.createCall();        
call.setTargetEndpointAddress( new java.net.URL(endpoint) );        
call.setOperationName( “doSpellingSuggestion” );        
call.setOperationName(new QName(”urn:GoogleSearch”, “doSpellingSuggestion”));        
call.addParameter(”key”, XMLType.XSD_STRING, ParameterMode.IN);        
call.addParameter(”phrase”, XMLType.XSD_STRING, ParameterMode.IN);        
call.setReturnType( XMLType.XSD_STRING );        
String ret = (String) call.invoke( new Object[] { “googlekey”, doc.getDocumentDescription()} );        
doc.setDocumentDescription(ret);

This block of code does a very simple thing…it calls the Google “doSpellingSuggestions” web service with two parameters: a key provided by Google, and a string for which the spelling suggestions should be generated. I used the current document description as my sample string for the web service and I put the results back into the document description - remember, this is just showing how you can call the web service, not doing anything really intelligent or useful from a business perspective

There is nothing special to E-Sourcing about the above code…this is really just using the Axis java classes to call a web service.

The second approach that can be used is to generate Java proxies for the web service calls. The open source Axis library includes a tool called “wsdl2java”. Using the WSDL for the web service, you can generate Java proxies. Java classes will be generated by the tool; these Java classes will then need to be compiled and included in E-Sourcing as a custom jar. Once they are part of the E-Sourcing deployment, they can be called like any Java API. If you were to examine the generated code, you would notice that it looks a lot like the raw web service code shown above…the generated classes really just provide a simpler interface to the same functionality.

Calling web services from a script can offer new possibilities for implementing integrations and other specialized functionality. As I said above, however, managing the security aspects is very important, so it should be done carefully and with thought.

I hope this article was interesting and helpful.

Good Luck.

As you know from the first posting, the first part of the RFx process was to have the many suppliers agree to the contractual terms and conditions. Once this was accomplished, it was on to collecting the updated “catalog” pricing from the suppliers.

We put a lot of thought into the best way to collect the updated pricing. Some of the key requirements for this  process were:

- The products offered by the suppliers varied greatly among the suppliers. This resulted in the number of products offered by suppliers varying greatly from one to supplier to the next.

- The number of products offered by suppliers could be as few as just a couple to as many as a couple thousand. We needed a solution that would address both extremes.

- In adition to collecting pricing information from the suppliers, it was also very important for the suppliers to see the detailed specifications about the products. In total, we had about 15 different specifications that we wanted the suppliers to be able to view during the catalog refresh process.

- The pricing that we were collecting from the suppliers was more advanced than a simple unit price. We needed to collect “tiered” pricing from the suppliers, but not in the traditional sense of tiers represented by quanities, but “named” tiers where the names provided meaning to the suppliers (logically, these named tiers represented “markets”)

- We needed the supplier to be able to add line items to the RFx for any new products they sell that should be part of our catalog.

The first approach we considered for the designing the RFx was to use the basic RFx functionality of E-Sourcing, building up an RFx with the superset of line items (all possible products for all suppliers). We discarded this as a viable approach due to the significant variety in what products each supplier would see.

The second approach we considered was using a separate E-Sourcing RFx for each supplier. In many cases, this approach would probably have been quite good: we would have created line items on the RFx for the various products offered by the supplier, used the “specifications” capability of E-Sourcing line items to provide the important information out to the supplier, and used the “attributes” capability of E-Sourcing to collect the various tiers of pricing. Unfortunately, this method did not adequately address the requirement that we need to have the suppliers provide additions to their catalog for new products they now sell. That is, we needed a way for the supplier to add line items to the RFx for any new products. Based on this limitation and also the fact that managing 250+ separate RFx’s was a bit concerning, we decided against this approach as well.

The approach that we settled on was a bit unique, but due to the high degree of configurability of E-Sourcing, it was an approach that was easy to implement and deploy. We decided that using Excel for the manipulation of the data by the supplier was the best option. Most suppliers would have experience with Excel and those suppliers that offered large numbers of products (1000s) would feel a lot more comfortable working in Excel to provide the updated pricing. Excel also offered the ability for the supplier to add new products.

Our approach was unique in that we used a standard E-Sourcing data structure to manage the product line items and associated those data structures with E-Sourcing contracts. We then created a separete contract for each supplier (in draft status), published that contract to the supplier, and allowed the supplier to export the pricing in Excel from within the contract. When the supplier was complete with their pricing work, they would upload the Excel spreadsheet, which was then processed by us and re-loaded into the standard E-Sourcing data structure holding the line items. Line items that existed had their prices updated. New line items were appended to the data structure. We built reports over the data structure that allowed us to analyze the product pricing, comparing like products when necessary. Ultimately, this data structure was used in the contract to represent the awareded line items and pricing.

What was really great about the solution we developed is that it used all standard functionality of E-Sourcing. It demonstrated the powerful configuration capabilities of E-Sourcing that allowed us to model a unique event in a slightly different way, but without writing a single line of code.

Obviously, there are a lot of finer details about how we put this all together. Nevertheless, I hope this posting has given you some ideas and next time you might “think outside the box” when you have an event that has unique attributes that may not align exactly with the standard functionality and use model of E-Sourcing.

In addition to requiring price updates from the suppliers, the customer also needed to use E-Sourcing to negotiate updated terms and conditions for their contract.

Overall, this scenario presented a very interesting use-case for E-Sourcing: to negotiate contract terms and conditions and follow that negotiation with solicitation of updated pricing from suppliers.

After much thought and analysis, we decided to structure the “event” as follows. We started by creating a basic E-Sourcing RFI. The purpose of the RFI was to negotiate the contract terms and conditions as well as to solicit some other information from the suppliers. The RFI was a very basic RFx in E-Sourcing: it consisted of only a few questions. One of the questions we defined was an “attachment question” - the purpose of this question was to have the suppliers upload a red-lined version of the draft contract terms and conditions, which were provided to the supplier as an attachment published by the E-Sourcing customer. This single RFI was published to the 250 suppliers.

Due to the large number suppliers participating in the RFx, we allocated three months to process the results and complete the contract negotiations.

Next week I will write about how we collected the updated pricing from the suppliers.

In the past couple of weeks, I have spoken to some people about the E-Sourcing / CLM Page Customization feature. This feature allows you to make configurations to the user interface in E-Sourcing without changing code. The types of configurations include: hiding fields, making fields required, changing the labels on fields, positioning fields on a page, and making fields not editable.

Page customizations are setup for a business object class or master data class. That is, each of the major business objects (Projects, RFx, Auctions, Master Agreements, etc) in E-Sourcing / CLM will have one page customization object. Each page customization object will consist of overrides that indicate the individual field configurations. For example, to make the Description field required in the Projects module, there will be a single override that specifies the field DOCUMENT_DESCRIPTION will have its required property set to a value of yes.

Each override in the page customization object will specify a single property for the field, so there could be many overrides for a single field. Unfortunately, the system does not perform many validations when the overrides are setup, so the specification of the field id must be done correctly; additionally, the system allow the same override to be specified for the same field multiple times. At run-time, however, the first one in the list of the overrides is the one that will be applied.

When page customization overrides are used as described above, they will apply to all instances of the business object class (e.g., all projects in the system would have the description being required). In many cases, however, there are requirements to conditionally implement page customization overrides. That is, the requirement might be that the description should only be required when the project is a specific type.

Conditional page customization overrides are available in E-Sourcing / CLM through additional fields on the page customization override. The fields are referred to as the dimension fields and they logically work as follows:

If the dimension field specified has the value as specified in the dimension field value then apply the override, otherwise, the override is ignored.

Following through with the example described above, if the description should only be required for Projects of a specific type (e.g., Category Project), then the dimension fields would be set as follows:

Dimension Field: DOC_TYPE

Dimension Field Type: Project Type

DImension Field Value: Category Project

Page customization overrides that are implemented with dimensions provide a lot of configurability in E-Sourcing and CLM. There are two important considerations that must be taken into account when implementing overrides using dimensions. The first consideration is that page customization overrides are applied when a document is entered and not applied again until the document is re-entered. This means that clicking save on the document will not re-apply the page customizations. I point this out because a common question I have heard is: could the page customization override dimension field be a value list value field and when the user changes the value in the drop down, could another field be hidden or made required. Unfortunately, this will not work well because changing the value list value will not refresh the page customization overrides. The second consideration is in the way the system process page customization overrides. They are processed in the order that the exist in the page customization object and as soon as an override is “found” for a particular field and property, it is applied. This means that the dimension field overrides must precede the non-dimensioned overrides so that they will be applied correctly.

An exmple of the above may be necessary to ensure it is clear. Suppose that the system has ten Project Types configured and there is an extension field named IT Project Type that only applies to projects that are of type IT Project. The requirement might be that the extension field should only be visible on the IT Project Types. This would be accomplished with two page customization overrides on the Project module: the first override would indicate that the IT Project Type field has the hidden property set to no when dimension field DOC_TYPE is set to IT Project Type. The second override would indicate that the IT Project Type field has the hidden property set to yes (no dimensions are required here). These two overrides would implement the requirement stated above.

As I mentioned above, page customizations are a very nice feature of E-Sourcing / CLM. They provide for a lot of powerful configurations to be made, yet require careful setup to ensure proper operation.

In a future posting, I will describe how scripting and hidden extension fields can help you do even more with page customizations.

Good luck!

User Defined Business Objects (UDOs) allow system administrators to configure an entirely new business object. They include all of the major features of E-Sourcing business documents including the document type / template creation model, configurable phase definitions, workflow, and user collaboration. Customers have found many uses for user defined business objects, but the two most common that I have seen are: a repository for non-disclosure agreements and a sourcing request (a way to capture request for sourcing from business users).

A base installation and setup of E-Sourcing does not come with UDOs enabled. UDOs are enabled via system properties that are set by the system user. There is a single property that turns them on and separate system properties that enable each of the five configurable UDOs. There are system properties for both purchaser side and supplier side enablement (UDOs are able to be seen by suppliers in addition to buyers if the requirements dictate such).

System Properties to enable UDOs (click to enlarge)

Once the system properties are enabled, UDOs are available for use in the system. However, E-Sourcing does not come with any security profiles that provide access to the UDOs; as a result, adjustments to the relevant security profiles are required to provide the appropriate access to the UDOs and the associated setup objects (document types and configurable phase definitions).

Security Profile configuration for UDOs (click to enlarge)

With the system properties set and the security profile settings established, a new navigation menu option will exist for UDOs. In the following image, only one of the five UDOs is enabled, but it does show how the common business document functionality is immediately available for the UDO:

Navigation Bar with UDO 1 Enabled (click to enlarge)

E-Sourcing provides a basic set of tabs and data that can be used on a UDO. Obviously, the real power is achieved by adjusting the layout through page customizations and adding new fields via extension definitions. Also, for UDOs, it is important to update the localized resources so that terms such as ”User Defined BizDoc” are changed to the appropriate term based on the configuration.

Default Configuration of a UDO (click to enlarge)

As you can see, there is a lot of functionality provided by the system without any configuration. However, the real power of UDOs is achieved through the inherent E-Sourcing flexibility that enables custom fields and user interface adjustments using the extension definition and page customization capabilities in setup.

To review, the key things to do when adding UDO functionality to an implementation are:

- Enable UDOs using system properties

- Update the appropriate security profiles with the necessary access rights

- Update the appropriate localized resources to reflect the true use of the UDO

- Add the necessary extensions and page customizations for the business functionality required

- Create the appropriate Document Types

- Create the appropriate Phase Configurations

- Add Workflow (if required)

In a future posting, I will look at a real  UDO example. In the mean time, I hope you found this information useful.

For those that don’t know about bookmarking reports in  E-Sourcing / CLM, let me explain the feature. All E-Sourcing / CLM reports can be bookmarked. Check out this screen shot that shows the toolbar that is displayed with a report when it is executed; notice the Bookmark Report option:

Report toolbar with Bookmark option (click to enlarge)

When a report is bookmarked using the button above, the user provides a name that will be saved for their use only. The system will save the name entered by the user and the filter parameters used for that execution of the report and make it available via an area on the Analysis page:

My Bookmarks - Available from Analysis page (click to enlarge)

As you can see, I have already setup five bookmarked reports. For me, the value in this functionality is the ability of the system to save the filter parameters I entered and to enable very easy access to the report from the Analysis page. Lets say, for example, that there is report that has filters for Organization Unit and some dates. Lets also say that I need to run this report once a week for the current quarter and a specific organizational unit. The first time I run the report for the quarter, I would bookmark it and those settings would be saved. Now, each time I need to run the report, I just run it from the bookmarks and those filter parameters will be populated with the report and it will execute using them.

Bookmarked reports can also be deleted. In my previous example, I would probably do that at the beginning of each quarter when I setup a new bookmark for that quarter. In the screen shot above, there is an edit button in the Bookmark heading - using that button provides me with a screen that I can use to delete unused bookmarks.

So, what do you think? Would using this feature help out your users? I suggest giving it a try.

A few weeks back, I posted about cleaning up the workbench page (Could the E-Sourcing / CLM Workbench be more useful?). One of the ideas I put in that post was to extend the capabilities of bookmarks by making a workbench page channel with access to bookmarks. This would really further extend the value of the bookmarked reports so that users have one-click access to their important reports right from their workbench.

That’s it for this week’s post. I hope this was helpful and that you consider using report bookmarking in your implementation.

Not to worry, however, because the flexible E-Sourcing / CLM scripting capabilities make implementing approval logic for clauses pretty straightforward. In this post, I will describe one approach that I put together for a recent sales demonstration.

The components of my clause approval configuration were:

- Created an extension (custom field) on the clause master data object that was a reference to the user group that is required to approve the clause

- Using page customizations, the approver extension field on the clause master data was made read only

- Using script definition, the approver extension field was populated with the name of the user group that is required to approve the clause. In many organizations, this would be some set of people from the procurement legal department.

The above three configurations provided the framework for the approval process by defining the approver on the clause master data.

In addition to the above configurations, one additional script definition was required. That script definition was implemented as a Field Data Edit script on the PHASE field of clauses. The script included two sets of logic:

- The first logic was based on the phase being changed to Approved. If the new phase was set to Approved and the user performing the change was a member of the approver user group, it was allowed; if the user was not a member of the approver user group, an error was generated and the phase change was not permitted. This logic ensured that only members of the approver user group approved the clause.

- The second logic was to send an email to the legal user group when the new phase of the clause was Review. This ensured that the members of the legal approval group received notification when there was a clause to approve.

So, what do you think? I understand that this is not using the E-Sourcing / CLM workflow approval capabilities, but is it good enough? Would this level of approval work for you? Based on what I have seen with customers, this approach would be more than suitable, but I would love to hear your feedback.

Overall, implementation of a solution like the above should not take more than a few days to prepare, configure, code, test, and deploy. For me, that is very exciting because it demonstrates the real power of the E-Sourcing / CLM capabilities such as extensions, page customizations, and scripting.

Thanks for stopping by and reading my latest post.

Rob

I thought today I would post about E-Sourcing / CLM Security Profiles. I have seen some questions on the SAP SDN about these recently and thought it would be a good topic to cover here.

Security Profiles are used in E-Sourcing to establish user roles and the permissions associated with those roles. Once setup, user accounts are associated with one or more security profiles which will result in the specific permissions the user has in E-Sourcing / CLM.

The permissions that are setup in the security profile include typical sorts of permissions such as Create, Edit, and View; there are also some specialized permissions that are available that are unique to the business object, configuration data, or master data. One of those permissions that resulted in a recent discussion is the permission called setup. This permission indicates whether or not the data can be managed via the E-Sourcing / CLM setup area. There are also permissions such as Create Template that are available on the major business objects (e.g., Projects, Auctions, RFx, and Master Agreements) that restrict access to the template creation functionality.

As with much of E-Sourcing / CLM there is a lot of flexibility built into the security profiles and how they are configured and associated with user accounts. Sometimes, however, this flexibility can lead to inconsistencies in the use and longer term maintenance headaches. When deciding how best to configure the security profiles in E-Sourcing / CLM, I suggest you really examine your organization and the roles in it. Here are some things to understand and establish before performing any configuration in the system:

What are the various roles of the members of my sourcing organization? Do these roles align with job titles or job descriptions?

Are the roles of the members of my organization strictly defined? Should the system be deployed with that strict definition?

How do the roles that the users have align with the functionality that will be used in E-Sourcing? For example, will only certain roles create and manage Projects? Contracts? RFxs? Auctions?

How much and how often will users’ roles change?

Could a matrix be created that lists the roles of the users and the functionality that those users will have access to in E-Sourcing / CLM?

Answering these questions will hopefully lead you down a path to a particular configuration approach. Here are a couple of approaches I have used in the past:

Create Security Profiles that align with job titles / job descriptions: With this approach, each job function in your organization has a related security profile in E-Sourcing / CLM. Each user is then assigned the security profile on the user account maintenance. If a user changes roles or leaves the organization the user account can be updated accordingly. If a user has multiple roles in the organization, they can be assigned multiple security profiles.

Create Security Profiles that define rights from a system standpoint and create user groups that associate the security profiles with roles: With this approach, security profiles might be defined based on use of the various modules (e.g., Projects, RFxs, etc). Instead of assigning the security profiles to individual user accounts, profiles are assigned to user groups and users are associated with one or more groups. In this approach, the group will likely align with the job functions.

Both of the above approaches can work well and your choice really will depend on how you want to maintain user accounts, security profiles, and your use of user groups. Regardless of the approach you select, the system provides a good audit report that shows how the security profiles are used. You can access this report from: Setup > System Administration > Administrative Reports > Security Profile Usage Summary.

I hope this article was interesting and you are inspired to review your use of security profiles and their setup in E-Sourcing / CLM.

A couple years ago, SAP added the ability to export the report results to a pre-formatted Excel spreadsheet. The Excel spreadsheet can include formatting, formulas, and even visual basic macros.

Due to the fact that the E-Sourcing / CLM reporting tool provides only very basic formatting, the Excel template functionality is quite useful for those reports that really benefit from formatting. Recently, for example, I worked on a report for a customer that had multiple queries in it to generate the result sets. We decided to use the Excel template functionality to take the results from the queries and format the data into a easily presentable single Excel worksheet. This was particularly useful because the report users were only casual users of E-Sourcing / CLM and much preferred to review and analyze the data in Excel.

If you are new to this functionality, I suggest starting with something very basic: change the column header and row data formatting in the template. This is done by performing the following steps (assuming you have already developed the query):

1. Create the Excel template. The template can be either an XLT (true Excel template) or XLS (an Excel worksheet). The Excel template should have one worksheet and the name of that worksheet should be the name of the query (not the internal name, but the internationalized display name). In the single sheet, you can apply formatting for the column headings and rows (search in the online help for “workbook templates” to see some shortcuts you can use in the template for the formatting).
2. Create an E-Sourcing / CLM File Attachment Container with the Excel template. In the create screen of the file attachment container, the purpose should be set to workbook template. The path name should be the name of the file and you should upload the Excel template file into the file attachment.
3. In the E-Sourcing / CLM report, set the workbook template to the file attachment container created in the previous step.

These steps will always be followed when you want to use Excel templates for reports. The real work will always be in creating, adjusting, and testing the Excel template.

A more advanced type of Excel template is to manipulate and/or format the raw data from the E-Sourcing / CLM report in a separate worksheet in the Excel template. This type of template is particularly useful where you would like to take data from multiple queries and format it onto a single worksheet.

To create the Excel template that formats raw data from multiple queries, you must do the following:

1. Create worksheets in the template, one for each of the queries in the report and name the sheets the same name as the queries. These should be in the same order as the queries in the report.
2. Create a new worksheet in the Excel template as the last sheet. You can use formulas in this sheet to “pull” data from any of the other sheets. There are different techniques you can use in Excel to accomplish; I typically will type “=” in the cell where I want the value, then click to the source sheet and select the source cell. The resulting value of the cell will be something like =Sheet1!a1.

For the posting, I created a simple query called Project Portfolio. The query pulls data from the E-Sourcing / CLM projects. I created an Excel template for the report to format the results into something more visually appelling and easy to print. First, I created the Excel template with 2 sheets:

Two Excel Worksheets (click to enlarge)

The first sheet (Project Portfolio) is the name of the query that I created. There is nothing special in this sheet. The second sheet (Project Portfolio Report), which has the focus when I save the workbook, includes the desired formatting and “pulls” the data from the Project Portfolio sheet. The first image shows the formatting I wanted:

Formatted Sheet (click to enlarge)

For each project that is part of my results set, I wanted three rows of display data. Each gray bar in the Excel template will be used to show a different project. The way this is done is by pulling the data from the source Project Portfolio worksheet. For example, the formula used in the first gray bar, first column is as follows:

Formula for pulling data (click to enlarge)

Notice that the formula for cell A3 has a formula in it to pull data from the first sheet in the Excel workbook. This technique allows me to take the rows of raw data from the generated sheet and reformat them into the block style on my template sheet. The next two images show the raw data and the formatted sheet.

Raw Data Project Portfolio Sheet (click to enlarge)

Formated Project Portfolio Sheet (click to enlarge)

This example shows how you can use simple Excel formulas to create visually appealing Excel exports for E-Sourcing / CLM report data.

Due to the fact that most capabilities of Excel are supported through the use of templates, complex formatting, logic, and adjustments can also be implemented using Excel Visual Basic macros. In the past, I have used such approach to dynamically create pivot tables in the Excel workbook using the raw data from the query as the source data for the pivot table. You can do some really exciting things if you want to invest the effort in programming Excel. One thing to keep in mind, however, is that once macros are included in the Excel template, Excel’s security comes into play - in certain cases, the users may not have the ability to execute the macros. You should review this topic with your IT staff before pursuing a complex Excel template of this sort.

Please let me know what you think about this posting and whether you would like more details about the use of Excel templates with E-Sourcing / CLM reports. I hope it helped you understand the capabilities and perhaps inspired you to try them out. Good luck and Happy New Year.

Many of you probably know that E-Sourcing provides options when it comes to making configuration changes and applying them to development, staging, and production instances. Some people choose to make the configurations using the XLS workbook capabilities, while others make the majority of the changes via the user interface. In either case, it is still important to consider how these changes should be moved to other instances of the application.

Some customers I work with are particularly rigorous about ensuring all changes are made in a development system, tested in a staging system, and carefully migrated to the production system. At the other end of the spectrum, I have also seen some customers be more aggressive and make configuration changes directly in the production instance. Where are you in this spectrum? Has your process worked well for you?

When I work with customers, I tend to prefer the more rigorous approach to change management. I think it is important that configuration changes are thoroughly tested and validated. I like this to be done in the development system, then migrated to the production system at the appropriate time - I think an evening or weekend is best to allow for further validation testing in those systems.

Unfortunately, applying this rigor really requires careful coordination, particularly if multiple people are working on the changes. E-Sourcing does not provide the necessary tools to easily identify “what has changed” and “has it been migrated to production”. As a result, those people making the changes need to carefully record each of the changes (I usually create a spreadsheet enumerating each change) and then create an export with those items. When done carefully and diligently, this works really well. It also helps set the next person making changes up for success - that person doesn’t need to figure out which system has the correct set of configurations; they can follow the same process.

Regardless of whether you choose to make your changes using an XLS workbook or via the E-Sourcing user interface, I would encourage you to use the E-Sourcing export data and import data tools as your means to move changes from a development system to a staging and/or production system. These tools are available in the setup area and can be configured to export only specific data elements.

In reality, this topic could have a small book written on it. Nevertheless, I hope it has made you think about how you manage changes and ensure your systems are configured consistently. Good luck!