Anyone has any idea----how to calculate the size in webMethods, like for any other programming language we used to have “LOC”(Lines of Code)Mechanism. Here how will we do the size calculation and if possible what are the esssentials steps need to be taken care of?

Regards,

You can do that via “Number of Flow Steps” mechanism. Though let me warn you that its not a easy approach.

You could also check the size of the package by looking at the zip file in the replicate/outbound directory of the IntegrationServer…

I’m not sure that the size of a package is useful as the \pub folder in a package could contain lots of large documents and the Flow services in the package could contain lots of unused services or large blocks of disabled statements.

Metrics like lines of code seldom measure what management is really attempting to get at (well designed, well tested functionality created per person per unit of time).

Mark

If you’ve got UNIX, or Unix shell tools installed, you could try this shell command to estimate LOC for a Flow service:

grep "<MAP MODE=\"STANDALONE\"\|<INVOKE \|<BRANCH \|<LOOP \|<EXIT \|<REPEAT \|<SEQUENCE " flow.xml | grep -v "DISABLED=\"true\""  | wc -l

This command applies to ‘flow.xml’ files under the package ‘ns’ folder. It basically counts each non-disabled FLOW statement as 1 line of code. Each standalone MAP step only counts as 1 LOC, irrespective of the number of connectors between the input and output (i.e. it does not treat each connector as a distinct assignment statement)

Adding '<MAPINVOKE ’ to the grep pattern above counts transformers within MAP steps, and adding '<MAPCOPY ’ counts all explicit connectors (I think…)

DSP and template files would be probably estimated by counting lines in each HTML or DSP file under the ‘pub’ folder. Java services can be estimated by base64-decoding the content of ‘’ within the java.frag files, then line-counting the decoded java fragment.

Adding to Sonam’s post:

If you run IS on Windows but you’d still like to run the command suggested by Sonam, you can try these utilities: [URL=“http://unxutils.sourceforge.net/”]http://unxutils.sourceforge.net/[/URL]

I use some of the commands frequently (ex. tail, grep, cut, wc) and they work great.

• Percio

I seriously question the value of any LOC type of measurement.

Thanks for adding Percio. Adding info on my preferred Unix-on-Windows environment: it’s cygwin ([url]http://cygwin.com/[/url])

Rob - You could be right.

I do, to somewhat degree, agree with Rob/Mark; But with some SEI/CMM Level 4/5 companies/projects you don’t have a choice but to do estimates for every project; “LOC” is the frequently used metric for estimation - and hence people try to extend this for webMethods FLOW services.

I (and am sure many developers) hate when @ certain quality conscious companies/projects, to even make a single line of change you have to go through five different quality process documents.

Thanks to Sonam for suggesting an easier way to calculate number of flow steps unix-script style.

Good points Saurabh. Companies do indeed use LOC as one data point in a larger set of data points to assist in their estimating efforts. I don’t know that I’ll ever agree that LOC is all that useful, though.

I’m reminded of a saying, though I can’t remember who to attribute it to: “Measuring software by counting lines of code is like measuring hardware by weight.” Interesting but not typically useful. I believe there are other estimation techniques that are better predictors.

Anyway, my kudos to Sonam for providing an approach to get the LOC.

Thanks guys.

Here’s another one-liner that calculates “effective LOC” of flow services in an IS instance. To run it, go to the /packages directory, and use ‘find’ with a wildcard pattern to identify the non-WM packages of interest.

This example counts LOCs of flows in all packages beginning with ‘DD…’:

find DD* -name "flow.xml" | xargs -n1 grep "<MAP MODE=\"STANDALONE\"\|<INVOKE \|<BRANCH \|<LOOP \|<EXIT \|<REPEAT \|<SEQUENCE \|<MAPINVOKE \|<MAPCOPY " | grep -v "DISABLED=\"true\""   | wc -l

Note, contrasted with my earlier post, this code counts each transformer (MAPINVOKE) and explicit connector (MAPCOPY) towards the LOC. This is because each transformer is effectively a subroutine invoke, and each explicit connector is an assignment statement.

Precisely counting Java LOC requires a more involved script - it’s easier to count the java.frag files and assume an average LOC per file.
Counting DSPs and HTML templates should be easy - just modify the statement above to search for suitable files and linecount the contents.

You can count the Java LOC by counting number of lines in the *.java files under package/code/source

You dont need anything complex as in going to java.frag files or am I missing something here? Remember this is for estimation purposes only!!

Thanks. I missed out on the consolidated Java files under /code/source/.

Just I had a look - there is one problem though with line-counting these files. IS inserts autogenerated code. The main issue is comments - IS recurses down a service’s input/output data structures and adds one comment for each each node. For eg:

// --- <<B2B-START(updateList)>> ---
// @subtype unknown
// @sigtype java 3.5
// [i] record:0:required packages
// [i] - field:0:required name
// [i] - field:0:required enabled
// [i] - field:0:required loadok
// [i] field:0:required servers
// [i] record:1:required in
...

A simple Java service with a complex datastructure would get “bulked-up” by this.

A approximation around this could be using an LOC counting tool, and getting it to exclude comments.

And actually, wikipedia entry goes over this in the “Measuring SLOC” section…

That’s a good reference - I read that same Wikipedia entry before posting.

My ‘strip-out comments’ idea is useful for Java services with complex input/outputs as IS seems to recurse down the input/output structures and autogenerate one comment per node.