12 articles about BS Lang, in reading order.
BS Lang
BS Lang is the one scripting language in Parsware, used by form rules, buttons, plugin steps, Custom APIs, processes and Studio screens. If you know a little JavaScript you can read it already. Here are variables, lists, objects, functions, conditions and loops in one short script, and the few places it differs.
BS Lang
The BS editor checks a script while you write it. A mistake is underlined within half a second, hovering says what is wrong, and a problems list under the script counts every error, jumps to each one and copies them all as text. Here is what it catches, and what it can't.
BS Lang
The BS editor offers names as you type. At the start of a line it lists the functions the script's host provides, the functions it imported from a solution script, and its own variables. After a dot it lists the value's methods. Here it is in a form rule from the Expense Limit sample, with what it offers and what it leaves to you.
BS Lang
Open a bracket after a function name and the BS editor shows what the call takes, with the argument you're on in bold and, for a function with several forms, each one to page through. Shift+Alt+F tidies the whole script, keeping your comments and your line breaks. Here is what each one does, and when formatting leaves a script alone.
BS Lang
Completion helps once you know roughly what to type. The eye button answers the question before that, what can this script call at all, with every function the script can use, its arguments and a line on what it does, in a list you can search. Here is where it is, what it lists, and the one-line version on a Studio binding that inserts what you pick.
BS Lang
Every Parsware script is BS Lang, but a form rule, a plugin step, a Custom API and a step in a process can't call the same functions. What each one gets depends on where it runs and what it has in front of it, a form, a record being saved, a caller or a running process. Here is each list, why it differs, and what happens when you call a function from the wrong one.
BS Lang
A server-side script can read more than the record it's working on. getRecord fetches one record, queryRecords and countRecords match one field, and runQuery takes a whole query with and/or filters, joins and totals. We used them in a plugin step that refuses an invoice when a customer would go over their credit limit, and in a Custom API that joins two tables.
BS Lang
When a plugin step and a Custom API need the same rule, write it once as a solution script and import it into both. We used the Shared Server Logic sample, where an approval limit decides both whether an order saves and what an API tells a partner, then changed the limit in one line and watched both follow. Here is how import and export work, and which scripts can import.
BS Lang
callService lets a server-side script post to another system, like a payment provider. The script never holds the address, only a service name. Each environment sets where that name points, so Test can use a sandbox and Production the real thing, and an environment that sets nothing reaches nothing. We took payments in a sample order app, and saw an answer, a refusal and a missing setting.
BS Lang
sendEmail sends a message through a mail service the environment names, just like callService. It never stops the script. It tells you whether the email went, and the script decides what to do about it. In the sample, a paid order records Sent or Not sent with the reason. Here is the call, what the mail service receives, and why an email step shouldn't refuse a save.
BS Lang
A server-side script can write a file to storage and read it back, and it can put a file into one record's File field. They're two different places for two different kinds of file. We exported expense claims as a CSV into a bucket, then attached a receipt to one claim and found it on the claim's form.
BS Lang
BS Lang runs in two places. A form rule runs in the browser, in TypeScript; a plugin step or a Custom API runs on the server, in C#. Those are two separate interpreters of one language, so we keep them the same with one shared set of test scripts that both must pass. This is a developer's look at how that works, and at the two cases where they still disagree.
