Sample Files

The sample files are located in the $MQ_HOME/common/standard/samples folder.

Sample Files
Folder/File Description 
/authentication/LdapHelper.JAVA
/authentication/rolecreation_sample.SQL
 Sample for LDAP authentication. 
/BackEndIntegration_Using_BW/Sample1.zip
/BackEndIntegration_Using_BW/Sample2.zip
 The following samples demonstrate how to integrate TIBCO MDM with TIBCO BusinessWorks using JMS.
  • Sample1.zip - Inbound Integration: In this sample, BusinessWorks sends a JMS message to add a record in TIBCO MDM and receives the response message on the outbound queue which can be consumed by BusinessWorks to verify if the record was added successfully.

    For more details, refer to Chapter 3 "Integration with TIBCO Business Works - Sample 1" of the TIBCO MDM System Administrator’s Guide.

  • Sample2.zip - Outbound Integration: When a record add event occurs in TIBCO MDM, the workflow sends a JMS message as an mlXML document wrapped in ebXML payload to BusinessWorks and the workflow is suspended till it receives a notification from BusinessWorks. Once the notification is received, the workflow is successfully completed.

    For more details, refer to Chapter 4 "Integration with TIBCO Business Works - Sample 2" of the TIBCO MDM System Administrator’s Guide. 

/BC-BW-Configuration/SampleBC-Configuration.csx
/BC-BW-Configuration/SampleBWConfiguration.zip
 This sample demonstrates how to integrate TIBCO MDM with datapools like WWRE and 1Sync using TIBCO BusinessConnect and TIBCO BusinessWorks.

For more details, refer to Chapter 7 "Configure TIBCO BusinessConnect and TIBCO BusinessWorks" of the TIBCO MDM Installation and Configuration Guide. 

/CIM Repackaging and code Reorg/8.0 Repackaging snapshot.xls
/CIM Repackaging and code Reorg/Repackaging impact on workflows and rules
 Sample documents to show repackaging impact. 
/configuration/insertConfigDefinition_sample.sql
 This sample demonstrates how to add a rulebase file entry to the ConfigurationDefinition table. The rulebase added here is executed on the record before it is published. The rulebase file must be present in the $MQ_COMMON_DIR/mydir/rulebase folder.

Edit the script to change the data as per your business requirement.

Connect to the database and run the following script:
sqlplus user/passwd@connect_string @insertConfigDefinition_sample.sql 

/CustomResponseHandler/CustomResponseHandler.java
 This sample demonstrates how to use more than one registration key to queue the event accordingly.

Refer to /CustomResponseHandler/Configuring Custom Handler.txt for more information. 

/EmailWorkitemHtmls/*.html
 Sample workitem emails that can be customized. 
/Java Transitions/CustomConditionEval.java
/Java Transitions/wfin26productadddeletev1.xml
 This workflow sample XML demonstrates how to use Java-based transitions.

Compile the CustomConditionEval.java file and place the generated class in the veloselpatches folder.

In this class, a rule is defined which specifies the condition in the Java format. The CDATA section contains the custom condition com.tibco.eval.CustomConditionEval.translateJmsToMLToDeleteRecord(Mcname) to be evaluated.

In this sample, if the master catalog name is "asset", the "DeleteRecord" activity is executed. If the master catalog name is not "asset", the "SaveRecord" activity is executed. Here is how it is implemented:

  • The method translateJmsToMLToDeleteRecord evaluates to true only if the MasterCatalogName is equal to "asset", so when the result returned is true, "DeleteRecord" Activity is executed. Based on the result returned, further transition path is decided.
  • The method translateJmsToMLToSaveRecord evaluates to true only if the MasterCatalogName is not equal to "asset". So, if the result returned is true, the "SaveRecord" Activity is executed. 
/JSXAPPS/CIMTestGIProject/*
 This project allows you to build custom screens for various operations such as the following using web services:

1. Record Add

2. Record View

3. Record Modify

4. Inbox (work item list)

5. Work Item detail

Refer to the /JSXAPPS/readme.txt for more information. 

/rulebase/connectsample.xml
/rulebase/disconnectsample.xml
/rulebase/queryanothercatalog
 This sample demonstrates how to create a "Shipping Address" relationship between two catalogs: Customer and Address.

The rulebase declares two variables: 

ADDRESSCATALOG link type="catalog"
ADDRESSRECORDS link type="record"

The constraint "AddressSoftlink" returns ADDRESS records having same CUSTOMERID as that of the record being processed.

The constraint "AddressConnect" connects ADDRESS records with the record being processed using the relationship "Shipping Address". The following syntax is used: 

<constraint>
	<name>AddressConnect</name>
	<description>
		Connect Address records using 'Shipping Address' relationship
</description>	
	<action>
		<connect>
			<literal>Shipping Address</literal>
<!--relationship name -->
			<var>ADDRESSRECORDS</var>				
			<literal>10</literal>
<!--quantity/optional/default 0-->
		</connect>
	</action>
</constraint>
 
rulebase/RulebaseCustomFunction.java
This sample code defines the interface for third party product validators.

The code generates a product ID and assigns it to the productid attribute if it does not exist. It then proceeds to call Standard validations. 

rulebase/nested/
 The files in this folder demonstrate how to embed one rulebase into another.

You can embed a rule in the following two rulebase format files:

CatalogValidation.xml: In the catalogvalidation.xml file the following rulebase exists: 

<constraint>
<name>Include embed1</name>
<description>RECORD_TYPE dropdown</description>
<action>
<include>
<literal>/standard/rulebase/embed1.xml</literal>		
	</include>
</action>
</constraint>

NewRecord.xml: The new record is embedded in newrecord.xml. 

<constraint>
<name>Include newrecord_embed</name>
<description>default propagation</description>
<action>
<include>
<literal>/standard/rulebase/newrecord_embed.xml</literal>
<literal>embed</literal>
</include>
</action>
</constraint>
 
/scripts/Create_Purge_Package.sql
 This script creates a SQL package that is used to purge all redundant data on TIBCO MDM 7.x installation. The SQL package contains the procedure PurgeHistoricalData, which actually purges the data.

For more information, refer to the usage guidelines documented in the SQL script. 

scripts/denyAccessForAFunction.sql
 This script shows how access to a new function may be denied for selected roles .

For more information, refer to the usage guidelines documented in the SQL script. 

/workflow/Merge_Match_Record_Sample/
MatcherWorkItem.html
MatcherWorkItemServlet.java
wfin26productaddapprovalv3.xml
wfin26productaddinternaleditv1.xml
rulebase/skipAttrlist.xml
 The folder contains files that demonstrate how to implement data quality using the match and merge records functionality.

The MatcherWorkItem.html and MatcherWorkItemServlet.java are used for the data quality work item page. You can customize the work item page. For more details, refer the TIBCO MDM Customization Guide. 

workflow/FilesAndDirectoriesCleaner.java
 This sample code demonstrates how to customize purging. The workflow wfin26purgev3.xml has a PurgeFilesThroughShellScript activity which calls com.tibco.mdm.workflow.engine.activities.FilesAndDirectoriesCleaner.purgeWorkDirectoryContent(purgefilepath,waitForPurgeProcessFlag).

This method purges all physical files for the redundant GeneralDocument entries using an OS-specific script.

The script is generated by the Purge activity (DocumentHandler.generateDocumentList()).

  • @param purgeFilePath — Relative path of the file having list of the files to be purged.
  • @param waitForPurgeProcess — A flag to identify whether the child process which executes the script should wait for parent process. The default value is false.

    The following is sample activity that calls the method FilesAndDirectoriesCleaner.purgeWorkDirectoryContent. 

    	<Activity Name="PurgeFilesThroughShellScript">
		<Action>InterpretCommand</Action>
		<Description lang="en">Delete the files associated with purged data</Description>
		<Parameter direction="in" eval="variable" type="string" name="purgefilepath">relativepath</Parameter>
		<!-- <Parameter direction="in" eval="constant" type="boolean" name="waitForPurgeProcess">true</Parameter> -->
		<Script format="bsh"><![CDATA[
			java.lang.Boolean waitForPurgeProcessFlag = null;
					if(waitForPurgeProcess != void)
				waitForPurgeProcessFlag = waitForPurgeProcess;	com.tibco.mdm.workflow.engine.activities.FilesAndDirectoriesCleaner.purgeWorkDirectoryContent(purgefilepath,waitForPurgeProcessFlag);
</Script>
	</Activity>
 
workflow/MqActivityInstPostProcess1.java
 This sample demonstrates how to write a custom workflow activity.

Every custom activity must be derived from MqActivityInstImpl and must provide the custom implementation in the "execActivity" method. The activity takes masterCatalogID as input parameter (which is extracted from MqWorkflowState) and the PostProcess method is called which in turn calls the stored procedure post_processor.

The method getRequiredParameters() returns the array of parameters required by this activity.

The workflow engine validates the input parameter list before the activity is called.

The method getOptionalParameters() returns the optional parameters. The list of optional parameters is used by workflow to ensure that no parameter values are carried over from a previous activity.

For example, if ReferenceStepID is not defined in the current activity, but was defined for a previous activity, this parameter has to be reset to 'null'. Otherwise, the value of ReferenceStepID used in the current activity will be the value carried over from the previous activity. 

workflow/wfin26productaddapprovalv3.xml
 This is sample workflow that demonstrates "product add approval". It routes the Product Add to editors and approvers.

Following are the main steps involved in this workflow:

InternalEdit — Uses 'New Product Introduction Edit' rules to identify editors.

InternalApproval — Uses 'Product Edit Approval' rules to identify approvers.

TargettedRejection — Uses 'Data Custodian' rules to identify data custodians. 

workflow/wfin26Test1.xml
 This sample workflow demonstrates how to spawn a subflow. The following is the sample fragment for spawning the subflow. 
    <Activity Name="TestSubflow">
        <Action>NoOperation</Action>
        <Description>Test Subflow</Description>
        <Execution>ASYNCHR</Execution>
<!-- Assign some more values -->
        <Parameter direction="in" type="string" eval="constant" name="eventState">SPAWNWORKFLOW</Parameter>
        <Parameter direction="in" type="document" eval="variable" name="InDocument">inDoc</Parameter>
     </Activity>

Activity implementation for Noop activity: The Noop activity expects no IN parameters and returns the same state. It is supplied primarily for routing when an empty workflow or an activity that does nothing is required. For example, a Noop activity can be useful in split/join transitions.