Welcome to another installment of This Week in Spring! It’s already June! Where. Does. The. Time. GO?? This week I’m in Chicago, IL, for the Chicago Coder Conference, Boston and New Hampshire for customer visits, London, England for Devoxx UK and Talin, Estonia for Geekout EE. If you’re around, be sure to say hi! Now then, we’ve got a lot to cover this week so let’s get to it!
We’ve covered various ways to debug scripts in JMeter, but now you have the ability to debug scripts step-by-step and receive updates in real time. Here’s how.
When I started to work with JMeter to create scripts, I was (as I’m sure we all do) feeling like debugging my scripts was way too cumbersome a process. By using the Debug Sampler and log() functions, it really felt like the old mainframe debugging days.
With Kofax Capture you can enter document index values in a validation screen or just confirm or changes values which have been recognized automatically. The validation screen form presents all fields of a document and the user has to confirm/change field values or enter data.
This is cumbersome and unnecessary for those kind of fields which have been filled automatically by barcode (see: “Kofax Capture – Document Separation and Barcodes“) or OCR , as the validity of these values can often be checked by simple rules or checks against databases.
Kofax Capture (Ascent Capture) always provided a scripting language to implement such checks: Softbridge Basic Language – SBL. This is a computer language from the 90s which is compatible to the old Visual Basic.
In the meantime Kofax Capture also supports C# and VB.NET for scripting within the validation module. The Softbridge Basic Language was deprecated with the current version 10.x of Kofax Capture. SBL might not be available anymore in the next main release of Kofax Capture.
Today most developers are using C# or VB.NET for new validation scripting, but a lot of Kofax Capture installations still exists, which are using SBL scripting in validation. During the migration of some of our older installations, I noticed that the official Kofax documentation for validation scripting with .NET is not very detailed and internet searching showed only fragments of a solution. So I decided to write this article to compare SBL and VB.NET scripting.
SBL has the advantage to be available out of the box as part of the Kofax Capture solution. With minimal efforts you can implement simple validation checks such as length verification in a short time.
If you want to use VB.NET or C# for validation scripting, you first have to install Visual Studio on a Kofax Capture admin workstation. You have to look at the Kofax Capture Developers Guide of the installed Kofax Capture version, to see what versions of Visual Studio are supported. I am using Kofax Capture 10.2 and Visual Basic 2010 for the following examples.
The naming of events in SBL and VB.NET
The following table shows the most important and most used events for scripting within the Kofax validation. For each event the table shows the internal event name of the SBL environment (Functions) and of the new VB.NET environment (Subs).
This example has two fields at document class level: ‘Barcode’ and ‘Status’:
|Field Barcode open||PreBarcode||Barcode_FieldPreProcessing|
|Field Barcode close||PostBarcode||Barcode_FieldPostProcessing|
|Field Status open||PreStatus||Status_FieldPreProcessing|
|Field Status close||PostStatus||Status_FieldPostProcessing|
I just skip the SBL scripting example and show the appropriate part of the VB.NET script.
' Class script: Project Imports Kofax.AscentCapture.NetScripting Imports Kofax.Capture.CaptureModule.InteropServices Imports System Imports System.Collections.Generic Imports System.Text Namespace ExampleDocClass <SuppressFieldEventsOnDocClose(false)> _ Public Class ExampleDocClass Inherits DocumentValidationScript <IndexFieldVariableAttribute("Barcode")> _ Dim WithEvents Barcode As FieldScript <IndexFieldVariableAttribute("Status")> _ Dim WithEvents Status As FieldScript '-------------------------------------- Private Sub Barcode_FieldPostProcessing(ByVal sender As Object, ByVal e As Kofax.AscentCapture.NetScripting.PostFieldEventArgs) Handles Barcode.FieldPostProcessing Try If Len(Barcode.IndexField.Value) <> 6 Then Throw New Kofax.AscentCapture.NetScripting.ValidationErrorException("Barcode nur 6-stellig!", Barcode.IndexField) End If Finally End Try End Sub '-------------------------------------- Private Sub Barcode_FieldPreProcessing(ByVal sender As Object, ByVal e As Kofax.AscentCapture.NetScripting.PreFieldEventArgs) Handles Barcode.FieldPreProcessing MsgBox("Barcode_FieldPreProcessing") 'This will skip the field 'e.SkipMode = PreFieldEventArgs.SkipModeEnum.SaveAndSkipField End Sub '-------------------------------------- Private Sub Status_FieldPostProcessing(ByVal sender As Object, ByVal e As Kofax.AscentCapture.NetScripting.PostFieldEventArgs) Handles Status.FieldPostProcessing MsgBox(Status.IndexField.Value) End Sub '-------------------------------------- Private Sub Status_FieldPreProcessing(ByVal sender As Object, ByVal e As Kofax.AscentCapture.NetScripting.PreFieldEventArgs) Handles Status.FieldPreProcessing MsgBox("Status_FieldPreProcessing") 'This will skip the field ********************** 'e.SkipMode = PreFieldEventArgs.SkipModeEnum.SaveAndSkipField End Sub '-------------------------------------- Private Sub DocPostProcessing(ByVal sender As Object, ByVal e As Kofax.AscentCapture.NetScripting.PostDocumentEventArgs) Handles Me.DocumentPostProcessing MsgBox("DocPostProsessing") End Sub '-------------------------------------- Private Sub DocPreProcessing(ByVal sender As Object, ByVal e As Kofax.AscentCapture.NetScripting.PreDocumentEventArgs) Handles Me.DocumentPreProcessing MsgBox("DocPreProsessing") 'This will SaveAndSkip the document ********************** 'e.SaveAndSkip = True End Sub '-------------------------------------- Private Sub Validation_BatchLoading(ByVal sender As Object, ByVal e As Kofax.AscentCapture.NetScripting.BatchEventArgs) Handles Me.BatchLoading MsgBox("Validation_BatchLoading") End Sub '-------------------------------------- Private Sub Validation_BatchUnloading(ByVal sender As Object, ByVal e As Kofax.AscentCapture.NetScripting.BatchEventArgs) Handles Me.BatchUnloading MsgBox("Validation_BatchUnloading") End Sub Sub New(ByVal bIsValidation As Boolean, ByVal strUserID As String, ByVal strLocaleName As String) MyBase.New(bIsValidation, strUserID, strLocaleName) End Sub End Class End Namespace
Finally we need the often used SaveAndSkipField (skip a field in validation) and SaveAndSkipDocument (skip a document in validation) functionality in the VB.NET environment. This has been put into the above scripting code as comments:
Details about Kofax Capture .NET Scripting can be found in the ‘Kofax Capture API Reference’, which is part of the documentation.
More blog articles about KC und KTM:
The post Kofax Capture Validation Scripting – from SBL to VB.NET for Dummies appeared first on codecentric Blog.
Containers based deployments are rapidly gaining popularity in the enterprise. One of the more popular container solutions is Docker.
Many view containers as virtual machines. They’re not. Well, kind of not. A container is a virtual walled environment for your application. It’s literally a ‘container’ inside the host OS. Thus your application works like it is in its own self-contained environment, but it’s actually sharing operating system resources of the host computer. Because of this, containers are more resource efficient than full blown virtual machines. You get more bang for your buck running a bare metal machine with a bunch of containers than you do running a bare metal machine with a bunch of VMs. This is why massive cloud computing companies running 10’s of thousands of servers are running containers. Google, Facebook, Netflix, Amazon are all big advocates of containers.
For the most part, Java is a very backwards compatible programming language. The advantage of this is that large systems can generally be upgraded to use newer versions of Java in a relatively easier fashion than would be possible if compatibility was broken on a larger scale. A primary disadvantage of this is that Java is stuck with some design decisions that have since been realized to be less optimal than desired, but must be left in place to maintain general backwards compatibility. Even with Java's relatively strong tie to backwards compatibility, there are differences in each major release of Java that can break Java-based applications when they are upgraded. These potential breaks that can occur, most commonly in "corner cases", are the subject of this post.
Sun Microsystems and Oracle have provided fairly detailed outlines of compatibility issues associated with Java upgrades. My point is not to cover every one of these issues in every one of the versions, but to instead highlight some key incompatibility issues introduced with each major release of Java that either personally impacted me or had more significant effect on others. Links at the bottom of this post are provided to the Sun/Oracle Java versions' compatibility documents for those seeking greater coverage.
Many programmers might try to find the value of x by passing all the array elements to the switch statement, but that is unnecessary.
In this quiz you don't need to calculate the return value of methodB, but you can pass the value, which is x/2 to the methodB first arg. You can find the result by calculating the following simple mathematical formulas.
I can't really have a Groovy retrospective without mentioning memory.
Over the last four years I have spent more time than any sane person should have to investigating memory leaks in production Groovy code. The dynamic nature of Groovy, and it's dynamic meta-programming presents different considerations for memory management compared to Java, simply because perm gen is no longer a fixed size. Java has a fixed number of classes that would normally be loaded into memory (hot-reloading in long living containers aside), whereas Groovy can easily change or create new classes on the fly. As a result, permgen GC is not as sophisticated (pre moving permgen to the normal heap anyway) and largely in Java if you experienced an Out-Of-Memory permgen exception then you would just increase your permgen size to support the required number of classes being loaded by the application.
In Part 1 of this series we looked at how to get Swift up and running. In this part, we will look the Differences between Java and Swift at a basic language level by creating the Swift classes and comparing them to Java. For this article, we will go over the basics of class construction.
Both languages are fundamentally statically typed class-based OO languages with single inheritance and interfaces. Furthermore, Swift includes the normal set of features that Java has including:
This post is one in a series about stuff formally trained programmers know–the rest of the series can be found here.
This post will look at the mighty tree, which is more a pattern than a specific data structure. The reason to understand the pattern is that so many of the data structures we will look at in the future use it, and a good understanding of it provides a strong basis to work from.
As an optionally typed JVM based language, Groovy offers syntax and construct features that make development more efficient for a wide variety of tools and applications. The downside to Groovy is the runtime overhead for type checking and conversions, and certain other Groovy magic. For lower-level or frequently run code in certain cases it is best to write in plain Java but for most code Groovy has options to make your code run just as fast as Java.
The tips in this article are based on my experience writing and optimizing Moqui Framework which currently has around 40k lines of Groovy code. In plain Java the code would easily be double or triple the size, and generally far more complex as well. Moqui was originally written in 100% Groovy aside from the framework API which is mostly interfaces and is written in Java. There are huge benefits to using Groovy for a framework like Moqui as there is a lot of complex functionality to implement and Groovy helps the code stay simple and small. This makes the framework more flexible and easier to write, improve, and maintain. With the limited resources of an unfunded open-source project, these are critical factors, but apply even to large teams working with much larger codebases.
This post is one in a series about stuff formally trained programmers know – the rest of the series can be found here.
In the previous post on Array, we saw that all read operations are Θ(1), which is awesome. An important reality of programming is everything is a trade off, so when you get fast reads with Array adding items when you don't know the collection size is expensive.
Spring Data is pretty convenient and speeds up development, avoiding boilerplate code.
However, there are cases where annotation queries are not enough for the custom functionality you might want to achieve.
After Exercises in Kotlin: Part 3 - Functions we now take a look at control flows and actually doing some basic exercises.
As mentioned earlier,
if/else is not just a statement but can also be used as an operator (in lieu of the ternary
? : operator.
They can be more or less divided into those categories:
I enrolled in the Functional Programming in Scala specialization on Coursera. It consists of 5 courses which will take around 180 days. The first course in the specialization is Functional Programming Principles in Scala. I already completed the first week and learned some stuff about recursive functions. So it’s time to share some knowledge.
Functions are an integral part of modern programming languages. In OOP they are called methods; in a functional world their name is functions, as you may guess. I’ve already published multiple articles about Scala functions. In this post, I want to speak exactly about recursive functions.
Groovy has a lot of nice and useful gems. One of them is the
FileTreeBuilder class. With this class we can create directories and files using a nice DSL with a builder syntax. The code already reflects the hierarchy of the directory structure, which makes it so more readable. We can use an explicit way of referring to methods in the
FileTreeBuilder class, but there is also support for a more dynamic version, where Groovy's dynamic nature comes to play.
In the first example we use the explicit method names. We can use the method
dir to create directories and the method
file to create a file. We can specify a name for the file and also contents:
This week, I had a student ask me how they could use a Java function to access the database from a Thymeleaf template. Thymeleaf is a modern templating engine. And accessing the database directly from Thymeleaf is certainly something you could do. But is it really something you want to do?
I’ve worked for a couple major retailers which had JSP templates accessing the database with static Java methods. It was not a good thing.
MFor those of you just getting to grips with JMeter, we’ve put together a three part ‘how to’ series on how to use this powerful tool. (Note: if you’re already a JMeter pro, you might want to take a look at this webcast on creating advanced load testing scenarios)
This week, we’ll focus on building scripts, running tests in non-GUI mode, logging and error messages, debugging, configuring JMeter, parameterization, and correlations.
As the old adage goes, with great power comes great responsibility. The advancements of Java 8 have provided us that power. It’s brilliant! We have true functional syntax in Java which allows us to write beautiful code in a much more terse fashion. We can perform functions in a parallel fashion using streams. We Java developers have finally entered the 21st century.
The thing is, most developers suck. Obviously this is a heavily loaded statement, and fundamentally what I think is good code is different to what you think good code is, but I think everyone can acknowledge there is a significant portion of the developer community in any language (but particularly Java) that just doesn’t know how to write good code. The introduction of the functional programming paradigm into Java 8 is in many cases like giving a Ferrari to someone who’s only just gotten their training wheels off (more cheesy analogies to follow).