SAP Business ByDesign internal events using the ChangeHistory reuse library

[Eneveux]

Following the series of blog posts related to the event-driven architecture for SAP Business ByDesign, we would like to show how to work with the Change History Reuse Library for Custom Business Objects. Custom and/or Standard business objects can take advantage of Change History. The example shown here, uses the SAP Business ByDesign Cloud Application Studio and a simple custom object.

Overview of Change History

The purpose of using Change History is so that we can not only track the changes that occur to the elements of our custom or standard business objects within the SAP Business ByDesign UI, but we can also capture these changes using the ChangeHistory.Read reuse library to send the changes to an external solution such as SAP Cloud Platform, Cloud Platform Integration (CPI) or any external system that can except OData. We use the ChangeHistory.Read reuse library because this is one mechanism by which to get change events from SAP Business ByDesign and then using OData Services, allow an external solution to utilize this information.

Technical Details about Change History

The use of the ChangeHistory.Read reuse library is an in-app extension using the Cloud Application Studio. In the example, we are creating a new custom business object. There are other documents and/or blogs, such as the Cloud Application Studio Help documentation, that covers the creation of business objects as well as how to setup the UI for the Changes tab that you can refer to if not familiar with how to do this. I touch on a couple of these areas but this blog is focused on the use of the ChangeHistory.Read reuse library.

Here is a simple business object that illustrates how to denote what elements we wish to track:

import AP.Common.GDT as apCommonGDT;



businessobject ChangeLog_EN {



        

		[ChangeHistory] element EmployeeID : LANGUAGEINDEPENDENT_MEDIUM_Name;

		[ChangeHistory] element FirstName : LANGUAGEINDEPENDENT_MEDIUM_Name;

		[ChangeHistory] element LastName : LANGUAGEINDEPENDENT_MEDIUM_Name;

		[ChangeHistory] element DOJ : LANGUAGEINDEPENDENT_MEDIUM_Name;





		action CheckChanges;



}

Fig 1.1

The first aspect of using ChangeHistory is using the annotation as shown above for the elements that you want to track changes for within your business object or standard object. For illustration, the business object above will track all four elements, but you can choose whatever subset of elements that you wish to track. By default, the annotation of [ChangeHistory] before the keyword element will allow us to eventually see the changes made to any of the elements in the SAP Business ByDesign UI on the Changes Tab that will be created once we Create Screens using the Cloud Application Studio for the object and setup the Changes table using the Cloud Application Studio UI Designer.

Fig 1.2

The “Changes” tab can be found on most SAP Business ByDesign forms such as for Sales Orders, Customer Accounts, Materials, etc.  We are adding that functionality to our custom object with the [ChangeHistory] annotation.  Another key is we add to our OIF on the Changes tab  ,the ChangeDocuments_EC from the /SAP_BYD_APPLICATION_UI/Reuse/ChangeHistory/ChangeDocuments_EC.EC.uicomponent.

This allows us then when in the UI of the custom business object, to see the Changes tab. When we click on the Changes tab we see the standard functionality from SAP Business ByDesign along with some other OIF changes that are documented in the Cloud Application Studio Help documentation.

Also, in the definition of the business object, you can see the action noted as CheckChanges [Fig 1.1].  When the button is clicked, it will trigger our ABSL code to get any changes to any of the annotated elements in the ChangeLog_EN.bo object and then update these changes in a second business object called CustomChangeHistory.bo.

This is the format for the ChangeHistory.Read reuse library …

ChangeHistory.Read(BusinessObjectName, NodeID, NodeName, FromChangeDateTime, ToChangeDateTime, ChangerUUID);

·         BusinessObjectName - mandatory

·         NodeID - mandatory

·         NodeName - optional

·         FromChangeDateTime - optional

·         ToChangeDateTime – optional

·         ChangerUUID - optional

If we were trying to use a standard business object we would use an SAP Business ByDesign object where BusinessObjectName is AP.CustomerInvoicing.Global.

In the example shown, we are getting all change information as shown from our custom business object ChangeLog_EN as changed in the UI and when the record is saved, storing the changes in the ChangeHistoryRootNode collection:

var ChangeHistoryRootNode = ChangeHistory.Read("ChangeLog_EN", NodeID2, NodeName);

We then instantiate the new business object CustomChangeHistory and then iterate through the changes made and store these in the new business object. The second business object, CustomChangeHistory.bo, will be updated with the changes that occur as changes are made to the fields in Fig. 1.2.  with our ABSL code when the CheckChanges button is clicked.

import ABSL;

import AP.Common.GDT as apCommonGDT;



var BOName = "ChangeLog_EN";

var NodeName = "Root";



var ChangedByUUID = Context.GetCurrentIdentityUUID();

var NodeID2:UUID;

NodeID2.content = this.GetFirst().NodeID;



var ChangeHistoryRootNode = ChangeHistory.Read("ChangeLog_EN", NodeID2, NodeName);





foreach (var results in ChangeHistoryRootNode)

{



	var newBO = CustomChangeHistory.Create();

	var itemData : elementsof CustomChangeHistory;

	var newItem;





	itemData.NewContent = results.NewContent;

	itemData.OldContent = results.OldContent;

	itemData.ElementName = results.ElementName;

	itemData.ChangeName = results.ChangeIdentityName;

	itemData.ChangeDate = results.ChangeDateTime;

	



	newItem = CustomChangeHistory.Create(itemData);



		

}

We can see the results of clicking the CheckChanges button in the screenshots of the debug of the ABSL code listed above and stored in the ChangeHistoryRootNode collection.

These changes are updated in our CustomChangeHistory business object.  Once we have these changes, we can then create in SAP Business ByDesign an OData webservice for our CustomChangeHistory object which again, will allow any external system that excepts OData … access to the change data.  This is an example of the OData web service created.

We can then test our OData Service using the provided URL from the SAP Business ByDesign OData Services and adding the collection to the end of the URL as shown.

Conclusion

There are different options as noted in the blog posts related to the event-driven architecture. Using the ChangeHistory.Read reuse library is one of those options.  If you have any questions or comments … let us know!