Monthly Archives: July 2014

Filtering Effective Dated Messages in BizTalk

I do a lot of work integrating systems with PeopleSoft using BizTalk. One of the core concepts in PeopleSoft is effective dating, that is the ability to have a history of an entity within the database controlled by an effective date field. For example PeopleSoft may hold an address for a company or person but we know the address will change on a particular date in the future. So you will have one entry effective dated in the past and another effective dated in the future. The advantage being that on the day the person or company moves addresses, the system will automatically pick up the correct address. It also helps keep an audit of historical addresses.

When consuming component interfaces exposed as web services using Integration Broker, all historical and future dated rows are returned. So how can you program a BizTalk map to only return the current row? The answer is to apply filtering via an inline C#

In this example I am using the CUSTOMER_MAIN CI from the Accounts Receivable module in PeopleSoft Financials to filter for current addresses. The incoming message has 2 different addresses (ADDRESS_SEQ_NUM), but one of them has 3 CUST_ADDRESS entries with different effective dates. The end result I want is 2 addresses, the current address for each ADDRESS_SEQ_NUM.

Create an inline c# functoid with the following code. Note that this was based on this tutorial here.

public System.Collections.Generic.List<int> duplicateList = new System.Collections.Generic.List<int>();
public bool IsDuplicate( int addressSeqNo, string effectiveDate, string effectiveStatus )

	 DateTime dt = Convert.ToDateTime(effectiveDate);
	 // Not interested in future dated dates
	 if (dt.Date > DateTime.Now.Date)
	   return true;

	 // Not interested in inactive addresses either
	 if (effectiveStatus != "A")
	   return true;

     if( duplicateList.Contains( addressSeqNo ) )
        return true;
     duplicateList.Add( addressSeqNo );
     return false;

Add EFFDT, ADDRESSSEQ_NUM and EFF_STATUS to it and connect it to a logical equals functoid, with false hard coded as the second parameter. This is then sent to the destincation node, as per the screenshot below.


Essentially this is filtering out any future effective dated rows and anything that is not active. Then is is pciking the first valid row, ignoring any others that follow. It relies on the order of the dates being sequential, but this is enforced via the PeopleSoft front end.