Product Documentation

    While it is expected that most applications communicating with SAKA will be modified to generate the SBI XML input file directly, there will be some period where it will be necessary to perform the batch operations expediently without having to wait for internal applications to be reprogrammed.

    To help during the transition process, the appliance's strongkeyliteClient.jar application includes an option called GenerateBatchInput in the application to take an ASCII text file, with a single record per line in the file, free of any comments or ornamentation, and convert it into an XML file conforming to the SBI schema.

    Typing the following command provides some help on the usage of GenerateBatchInput:

     

    java -cp sakaclient.jar GenerateBatchInput

     

    When run, it results in the following output:

    Parameter

    Explanation

    <input-file-name>

    The full file-name of the plain ASCII input file containing the lines of text to be converted to SBI in an XML file.

    <output-file-name>

    The full file-name of the XML file that will contain the resulting XML. It is strongly recommended that convention for these filenames is established so there are no over-write errors. StrongKey recommends the following: the domain ID, followed by a hyphen, followed by the source application name or requester, followed by a hyphen, followed by the date-timestamp.

    An example would be 1-PANDB-20100920154535.xml, indicating that the XML file belongs to domain ID 1, was sourced from the PAN database application and was created at 3:45:35PM on 20 September 2010. This will ensure that the same application creating the same text file for a second batch operation will not overwrite the first file on the appliance even as it is being processed (as it will be likely very difficult for any application to write out two files in the exact same second).

    <DID>

    The unique encryption domain identifier in which this batch job will be processed.

    <job-name>

    A helpful job-name that can be embedded inside the XML file, so the resulting output can be processed by the client application meaningfully. This name can be an identifier string that has meaning in the application environment.

    <Encrypt|Decrypt|Delete|Search>

    One of the four cryptographic operations requested for this XML file.

    <number-of-records>

    The number of lines in the plain ASCII text file. While this is not meant to be a hard number that will prevent the appliance from processing the XML file if the actual number is more or less than this number, it is a helpful guide to humans who may be reviewing the XML file.

    [SAKA.xsdlocation-name]

    An optional parameter specifying the full path location of the SAKA.xsd file against which the strongkeyliteClient.jar application builds the XML document. On the SAKA server, this parameter is unnecessary since the file exists in /usr/local/strongauth/strongkeylite/etc. However, it may be useful to generate this XML file on other computers—PCs or other servers—without needing access to the appliance itself for generating the XML input file.

    In that case, copying SAKA.xsd to any location on one's PC or server (along with strongkeyliteClient.jar and its supporting libraries, of course) makes it possible to generate this XML input file outside the appliance. SAKA.xsd must be present at the specified location, otherwise the strongkeyliteClient.jar application will not know what type of XML to generate.

    In the current directory where the strongkeyliteClient.jar file exists, if a plain ASCII text file exists—plain-input.txt—including the following lines of text...

    1111222200000001
1111222200000002
1111222200000003
1111222200000004
1111222200000005
1111222200000006
1111222200000007
1111222200000008
1111222200000009
1111222200000010

    ...the following command will convert it to an XML file in the SBI format...

    java -cp sakaclient.jar GenerateBatchInput plain-input.txt 1-ABCD-20100920T163300.xml
	1 ABCD-PAN-Conversion Encrypt 10

    ...and resulting in the following XML file:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SKLESBatchInput xmlns="http://strongkeylite.strongauth.com/SKLES201009">
    <DomainId>1</DomainId>
    <JobId>ABCD-PAN-Conversion</JobId>
    <Transaction>Encrypt</Transaction>
    <InputNumber>10</InputNumber>
    <InputValues>
        <Input>1111222200000001</Input>
        <Input>1111222200000002</Input>
        <Input>1111222200000003</Input>
        <Input>1111222200000004</Input>
        <Input>1111222200000005</Input>
        <Input>1111222200000006</Input>
        <Input>1111222200000007</Input>
        <Input>1111222200000008</Input>
        <Input>1111222200000009</Input>
        <Input>1111222200000010</Input>
    </InputValues>
</SKLESBatchInput>

    The following figure shows the use of the optional SAKA-location-name parameter since this was executed on a PC where the SAKA.xsd file was not automatically available:

    There are no limits to the number of records that may be included in an SBI element of the XML file; however, very large numbers of records may require that the Java executable program be provided more “heap memory” for its execution by supplying an “-Xms” and/or “-Xmx” option, as follows:

    java -Xms2048m -Xmx4096m -cp sakaclient.jar GenerateBatchInput plain-input.txt 1-ABCD-20100920T163300.xml 1 ABCD-PAN-Conversion Encrypt 1000000 SAKA.xsd

    Indicating that this generation process use 2GB of heap-memory initially when creating the Java Virtual Machine (JVM) to execute the program, and use a maximum of 4GB during the execution, if needed.

    The resulting XML file may now be transferred to the appliance for batch processing.