Using MDM Java APIs to add Text(type) taxonomy attribute allowable values
Paras Arora
Now consider this a continuation of my previous blog on MDM Java APIs (taxonomy attributes):
Using MDM Java APIs to retrieve Taxonomy attribute Values - this was while attempting to replicate all capabilities of MDM Data Manager using MDM Java APIs.
During the same exercise I had made up my mind, to develop a highly customised data manager using MDM Java APIs & Portal UI technologies. As of now, my Custom Data Manger is under build and would have to wait before I share the same with the community.
For now, I am sharing the following solution for the scenario, which propped up as a result of brief conversation over a cup of Tea.
"MDM Taxonomy attributes can have a set of allowable values for taxonomy attributes of type text for e.g. different country names for attribute 'Country', different values for attribute 'type' of a Material etc.While MDM Data Manger provides option to add allowable values for a Taxonomy attribute at design time, which are utilised in custom built MDM - Portal applications or MDM Business packages. What if the user wants to add a value to the set of allowable values for a text type taxonomy attribute at runtime? , which would enable him an additional option to select from a list of allowable values for a Taxonomy attribute. I couldn't find an out of the box set of API methods/Interfaces, which can help us achieve the same"
After a lot of analysis and indepth study of MDM Java APIs, I could find out a mechanism using which we can replicate this design time functionality of MDM Data Manager, at runtime by using MDM Java APIs.
The algo/code snippet given below can be re-used, after further customizing or extending as is needed.
We start at the point where we have retrieved the attribute object (retrieved using Attribute ID, which in turn is retrieved from current record object, refer embedded blog link for details)
Depending upon the screen design i.e. the number of entries you want the end user to enter for addition to list of allowable values for text type taxonomy attribute one can utilize the following lines of code.
int textAttrValueCount = 10; // allows the user to add 10 values to the set of allowable values for a text type taxonomy attribute
for (int i = 0; i < textAttrValueCount; i++)
{
TextAttributeValueProperties textValue = new TextAttributeValueProperties();
baseName = "TextValue" + i + System.currentTimeMillis();
MultilingualString textValueName = MultilingualHelper.createMultilingualString(regDefs, baseName);
textValue.setName(textValueName);
baseName = "Tooltip" + i + System.currentTimeMillis();
MultilingualString tooltip = MultilingualHelper.createMultilingualString(regDefs, baseName);
attr.addTextAttributeValue(textValue);
}
attr = text type taxonomy attribute object to which allowable values are to be added
Utilizing the code piece or the approach outlined above one can customize and extend MDM Business Packages (so that it gives end user the option to add to allowable values for a text type taxonomy attribute)or integrate the same into a webdynpro application providing cover to MDM repository and give end user the option which is otherwise available on at design time i.e. using MDM Data Manager.
Showing posts with label Web Dynpro. Show all posts
Showing posts with label Web Dynpro. Show all posts
Monday, February 16, 2009
Tuesday, February 3, 2009
Central MDM Business Partner Creation Scenario with Galaxy (BPM) - Part I Satyajit Chakraborty
Central MDM Business Partner Creation Scenario with Galaxy (BPM) - Part I
Satyajit Chakraborty
With NetWeaver CE Ehp1 SAP has announced the availability of the new BPM tool called Galaxy. There have been a lot of blogs in SDN talking about Galaxy and also showcasing a few use cases. This blog is the first part in a series of two (or maybe three) blogs about a new scenario where I talk about managing a master data management scenario with Galaxy and the new rules framework.
The first part details out the scenario, lists out notable features about the scenario and finally shows the scenario as modeled in Galaxy. The second part will contain more implementation details.
The process is that of a new business partner creation in MDM in the central MDM scenario. It can be demonstrated using the following diagram
Process Specification
Note that even though the diagram is for a vendor creation scenario it can be re-used in the business partner creation scenario as well.
Before we look at the process modeling in Galaxy here are a few things to note about the process:
§ 3 roles: Vendor Manager, Accounting Agent, Procurement Agent
§ Parallel enrichment of data by the Accounting Agent and the Procurement Agent
§ Manual/Auto approval of a record is based on a rule
§ DUNS number assignment is automatic (not entered by either of the agent roles)
From MDM perspective the things to note are:
§ In the first step of the process the Vendor Manager searches for a record in MDM and absence of appropriate results allow him/her to create a new record in MDM with the search parameters
§ All enrichments happen on an already created and checked-out record
§ Before persisting any change the record should undergo MDM validations defined in the repository
§ When a record is approved it is checked-in and the process ends
A few implementation considerations that are worth mentioning are:
§ Usage of the standard SAP delivered Business Partner repository
§ Web Dynpro for Java for the user interaction steps in the process
§ Auto or Manual approval of a record is based on the presence or absence of the SSN entry respectively for the record
§ Usage of MDM web services and Java APIs in cases where there were no web services
§ Role based access to the application for the two different agent roles
With all that in mind let's look at the process model in Galaxy. This blog is not about how to model processes in Galaxy and so I'll just put the final completed process model here. If you are interested in learning modeling with Galaxy you can find a lot of good resources about both Galaxy modeling and BPMN modeling (quick hint: search SDN for "Ginger Gatling Galaxy").
BPM Model
Looking at the process model you might have already noticed that there is a disparity between the original process specification and the modeled process. The first step of searching for a business partner by the Vendor Manager is missing from the Galaxy model! The reason is this: the process to create a new business partner is started only if the Vendor Manager chooses to do so.
Hence there is a need to remotely start the process and not a manual start via the NWA tool. The future parts of this blog will also show the implementation details of how to start a Galaxy process remotely.
Satyajit Chakraborty is part of the BST Innovation Center team in Palo Alto.
Central MDM Business Partner Creation Scenario with Galaxy (BPM) - Part I
Satyajit Chakraborty
Satyajit Chakraborty
With NetWeaver CE Ehp1 SAP has announced the availability of the new BPM tool called Galaxy. There have been a lot of blogs in SDN talking about Galaxy and also showcasing a few use cases. This blog is the first part in a series of two (or maybe three) blogs about a new scenario where I talk about managing a master data management scenario with Galaxy and the new rules framework.
The first part details out the scenario, lists out notable features about the scenario and finally shows the scenario as modeled in Galaxy. The second part will contain more implementation details.
The process is that of a new business partner creation in MDM in the central MDM scenario. It can be demonstrated using the following diagram
Process Specification
Note that even though the diagram is for a vendor creation scenario it can be re-used in the business partner creation scenario as well.
Before we look at the process modeling in Galaxy here are a few things to note about the process:
§ 3 roles: Vendor Manager, Accounting Agent, Procurement Agent
§ Parallel enrichment of data by the Accounting Agent and the Procurement Agent
§ Manual/Auto approval of a record is based on a rule
§ DUNS number assignment is automatic (not entered by either of the agent roles)
From MDM perspective the things to note are:
§ In the first step of the process the Vendor Manager searches for a record in MDM and absence of appropriate results allow him/her to create a new record in MDM with the search parameters
§ All enrichments happen on an already created and checked-out record
§ Before persisting any change the record should undergo MDM validations defined in the repository
§ When a record is approved it is checked-in and the process ends
A few implementation considerations that are worth mentioning are:
§ Usage of the standard SAP delivered Business Partner repository
§ Web Dynpro for Java for the user interaction steps in the process
§ Auto or Manual approval of a record is based on the presence or absence of the SSN entry respectively for the record
§ Usage of MDM web services and Java APIs in cases where there were no web services
§ Role based access to the application for the two different agent roles
With all that in mind let's look at the process model in Galaxy. This blog is not about how to model processes in Galaxy and so I'll just put the final completed process model here. If you are interested in learning modeling with Galaxy you can find a lot of good resources about both Galaxy modeling and BPMN modeling (quick hint: search SDN for "Ginger Gatling Galaxy").
BPM Model
Looking at the process model you might have already noticed that there is a disparity between the original process specification and the modeled process. The first step of searching for a business partner by the Vendor Manager is missing from the Galaxy model! The reason is this: the process to create a new business partner is started only if the Vendor Manager chooses to do so.
Hence there is a need to remotely start the process and not a manual start via the NWA tool. The future parts of this blog will also show the implementation details of how to start a Galaxy process remotely.
Satyajit Chakraborty is part of the BST Innovation Center team in Palo Alto.
Central MDM Business Partner Creation Scenario with Galaxy (BPM) - Part I
Satyajit Chakraborty
Thursday, January 29, 2009
Central MDM Business Partner Creation Scenario with Galaxy (BPM) - Part III
Central MDM Business Partner Creation Scenario with Galaxy (BPM)
The first two parts of this series dealt with overview of the process (part I) and some implementation details (part II) respectively. In this third and final part I'll talk about the rules integration as well as remote invocation of the process.
As a memory refresher - we wanted a rule such that if the new business partner record doesn't have a SSN entered the record should be manually approved. Otherwise it should be approved automatically.
Think of this rule as a function which takes two arguments - "context" which passes the entire web dynpro context to the function and "return" of type Boolean which is set to true if manual approval is needed and false otherwise. The rule engine will pick up the SSN entry from the context, evaluate it and set return accordingly.
Here's the rule at design time:
image
Since the return type is Boolean we can conveniently assign this function as a condition to the non-default gate of the exclusive choice gateway. Check the process model in part I for clarification.
For example, if you have called the ruleset as "checkApprovalMethod" and if the non-default gate for the exclusive choice is the one for auto-approval, then as a condition for this gate you can write: not(checkApprovalMethod(Context,IsAutoApproval)). So this gate will be taken by the process if the condition evaluates to true. Here Context and IsAutoApproval are two data-objects that you have created. IsAutoApproval is of type Boolean here.
So much for the rule, let's look at the way to start the process remotely. True to BPMN standards, every Galaxy process model has a Start event which can be bound to a web service interface and an operation of that interface. We can also handcraft wsdl files to suit our needs and bind it to the start event.
For example, in this scenario I had to pass the record ID to the process context when the process is started. So I added the following XML element to the default process start web service WSDL provided by Galaxy.
image
Logically if we invoke this web service operation manually it should start the process and that is exactly what happens! All you need to do is find out the URL of the wsdl of this web service from the NWA and the rest is easy. Since I was using web dynpro, I simply created an adaptive web service model out of this web service and invoked the operation on click of a button.
That brings us to the end of this series. Let me know if you have any questions regarding the implementation or about this scenario by posting your comments.
Satyajit Chakraborty is part of the BST Innovation Center team in Palo Alto.
The first two parts of this series dealt with overview of the process (part I) and some implementation details (part II) respectively. In this third and final part I'll talk about the rules integration as well as remote invocation of the process.
As a memory refresher - we wanted a rule such that if the new business partner record doesn't have a SSN entered the record should be manually approved. Otherwise it should be approved automatically.
Think of this rule as a function which takes two arguments - "context" which passes the entire web dynpro context to the function and "return" of type Boolean which is set to true if manual approval is needed and false otherwise. The rule engine will pick up the SSN entry from the context, evaluate it and set return accordingly.
Here's the rule at design time:
image
Since the return type is Boolean we can conveniently assign this function as a condition to the non-default gate of the exclusive choice gateway. Check the process model in part I for clarification.
For example, if you have called the ruleset as "checkApprovalMethod" and if the non-default gate for the exclusive choice is the one for auto-approval, then as a condition for this gate you can write: not(checkApprovalMethod(Context,IsAutoApproval)). So this gate will be taken by the process if the condition evaluates to true. Here Context and IsAutoApproval are two data-objects that you have created. IsAutoApproval is of type Boolean here.
So much for the rule, let's look at the way to start the process remotely. True to BPMN standards, every Galaxy process model has a Start event which can be bound to a web service interface and an operation of that interface. We can also handcraft wsdl files to suit our needs and bind it to the start event.
For example, in this scenario I had to pass the record ID to the process context when the process is started. So I added the following XML element to the default process start web service WSDL provided by Galaxy.
image
Logically if we invoke this web service operation manually it should start the process and that is exactly what happens! All you need to do is find out the URL of the wsdl of this web service from the NWA and the rest is easy. Since I was using web dynpro, I simply created an adaptive web service model out of this web service and invoked the operation on click of a button.
That brings us to the end of this series. Let me know if you have any questions regarding the implementation or about this scenario by posting your comments.
Satyajit Chakraborty is part of the BST Innovation Center team in Palo Alto.
Subscribe to:
Posts (Atom)