In-house scripting approach to generate call hierarchy in middleware application project

Slicing and dicing the data flow processes (in middleware application projects) is helpful to analyze, redesign or to generate documentation.  When vendor product limitations are visible (for example, what contents could be generated as documentation) the choices are either buy third party tools or just-meet-the-need in-house tools – a typical buy vs. design decision.  A key benefit of the in-house tools is they fill in the gap to serve the short-time purpose the solutions don’t need to address variant of the problems.

In this blog I am presenting a scripting approach to generate call hierarchy of a given data flow process if the product doesn’t support such call hierarchy documentation.

Objective

The objective is an approach to print call hierarchy of a data flow process with leaf nodes ending with external call or no external call.

Sample Call Hierarchy:

• Processes/CreditCheck process
  • Processes/CheckPremium process
    • No external call
• Processes/CheckAddress process
  • SharedResources/References/AddressService_Partner partner
    • SharedResources/ReferenceWSDL/AddressServiceConcreteWSDL.wsdl#GetCompleteAddress
  • SharedResources/References/PostalService_Partner partner
    • SharedResources/ReferenceWSDL/PostalServiceConcreteWSDL.wsdl#ValidateAddress
  • SharedResources/References/BusinessRuleService_Partner partner
    • SharedResources/ReferenceWSDL/BusinessRuleServiceConcreteWSDL.wsdl#IsAcceptableArea
• Processes/CheckExternalCredit process
  • Processes/ComputeCreditScore process
    • No external call
  • SharedResources/References/CreditAgencyService_Partner partner
    • SharedResources/ReferenceWSDL/CreditAgencyService_ConcreteWSDL.wsdl#IsAcceptableScore

Design Tips

1.  Understanding interested types and model the call hierarchy

Depending on your need you may limit the interested types to use in the call hierarchy.  I chose (a) the process, (b) sub-process and (c) partner as interested types to build call hierarchy output that generates Call Hierarchy, like the sample above.

Next, model the call hierarchy.  For simplicity, I choose the just three classes with notable characteristics as mentioned below:

• The root of the call hierarchy is a Process class with Activity and Partner classes.
• ProcessType for the process or sub-process.
• ActivityType for the activities in the process/sub-process.
• PartnerType for the partner.
• WeavingKey is to build the call hierarchy.
• StoredFilePath is the file where the Activity or Partner is stored.  It is convenient when you are using vi (or a variant such as gvim) to browse from one file to another.  Try this out!

2. Transform stored information

Study your product’s project files and generated files.  I assume you are comfortable with knowledge of your middleware development products.

Also in this step, understand the transformation logic to transform step 1 interested types (process, sub-process and partner information) to essential call hierarchy model objects (ProcessType, ActivityType and PartnerType).  Typically the right choice for implementation of such transformation logic is XSLT, when the processes/sub-processes is in XML files.

3. Weave the shredded parts

Finally, build the call hierarchy using the call hierarchy model objects and weaving key.  TBD: add more details.

Script Tips

If the product uses XML/XSLT to store the process/sub-process details then the scripting is achievable using the XSLT, Ant, and Perl.

• Use Ant to select process/partner files.
• Use XSLT to transform process/partner files into call hierarchy model objects (ProcessType, ActivityType and PartnerType).
• Use Perl to weave the call hierarchy.

XSLT Snippet:

<!– For every interested activities –>

       <xsl:template match=“//product:activity”>

              <xsl:if

                     test=“isCallableActivity(.) and not(filtered(.))”>

                     <Activity>

                           <Name>

                                  <xsl:value-of select=“normalize-space(./@name)” />

                           </Name>

                           <Type>

                                  <xsl:value-of select=“normalize-space(./pd:type)” />

                           </Type>

                           <ResourceType>

                                  <xsl:value-of select=“normalize-space(./pd:resourceType)” />

                           </ResourceType>

                           <xsl:choose>

                                  <xsl:when test=“./product:type/text()=CallProcessActivity’”>

                                         <xsl:call-template name=“printCallProcessActivity”>

                                                <xsl:with-param name=“node” select=“.” />

                                         </xsl:call-template>

                                  </xsl:when>

                                  <xsl:when

       … … … …

                           </xsl:choose>

                     </Activity>

              </xsl:if>

       </xsl:template>

Conclusion

With Perl, XSLT and Ant experience the call hierarchy generation scripts could be created in a few hours.  There are few commercial/open source middleware products, including TIBCO Designer Business Works (v5.7.x) store process in XML files, where this blog could be applied to write call hierarchy generation scripts.  May be the solution in this blog is not the efficient means to construct the call hierarchy.   On the other hand, the alternate approaches such as database driven approach and xml query driven approach may be better to slice and dice several data flow processes but what if your product’s next version comes with call hierarchy?

About these ads

Tags: component diagram, design, linkedin, uml metamodel, web characteristics