27 articles about BS Lang, in reading order.
Parsware Platform
Add your own buttons to a list's or a form's command bar. Most need no code, because they open a view, start a record or open an address. When the button depends on what the user ticked or typed, it runs a short script.
Parsware Platform
A saved query in Parsware is one question with one definition. A report fills its table from it, and a server script runs it by name, so correcting the question once corrects every answer that names it, in this environment and in the next one the solution goes to.
Parsware Platform
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.
Parsware Platform
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.
Parsware Platform
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.
Parsware Platform
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.
Parsware Platform
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.
Parsware Platform
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.
Parsware Platform
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.
Parsware Platform
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.
Parsware Platform
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.
Parsware Platform
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.
Parsware Platform
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.
Parsware Platform
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.
Parsware Platform
Parsware has several places to put a rule. Form rules make a form respond as you type. Plugin steps decide what may be saved, however it's saved. Custom APIs answer other systems, scheduled jobs run on a clock, and processes carry work between people. This guide says which one to reach for, with a real example of each.
Parsware Platform
A form rule runs in the browser and changes the form as you type. In the Expense Approval sample, typing "rejected" into Status shows a Rejection reason and makes it required, and approving the claim hides it again and locks the amount. Here is the form, the three rules behind it, and the one script they share.
Parsware Platform
A claim over 1,000 needs an approval note. The form can show that as you type, but only a plugin step makes it true, because it runs on the server whatever saved the claim. We imported a spreadsheet of claims past the form and watched two rows refused with the step's message, then looked at how one script holds the limit for both sides.
Parsware Platform
A server validation rule is a plugin step that refuses a save and says why. We added one from scratch, "a claim over 10,000 needs a purchase order", then watched the editor catch a misspelt function and the form show the step's message when we saved a claim that broke it.
Parsware Platform
A plugin step is registered against a table, a write, a stage and an order, and the stage decides the most. We put a second step behind the order-stock sample's own, watched a refusal before the write undo the stock the first step had taken, then moved the same refusal after the write and watched the order line stay.
Parsware Platform
The answer to "is there enough stock?" isn't on the order line. It's on the product. We saved three order lines against a product with 10 in stock and watched a plugin step read the product, take the stock and log the movement, or refuse the line, then read the script that does it.
Parsware Platform
Not every server rule refuses. This one approves. A claim of 50 or less is marked approved as it's saved, by a plugin step that sets a value on the record before it's written. We saved a taxi fare and a hotel bill, watched only one come back approved, then watched the sample's own lock stop the approved one being edited up.
Parsware Platform
A plugin step that runs after the response has nobody to tell when it fails. So it tries five times, and then it waits on a list. We made one fail for a real reason, read the failure, fixed the setting it needed, and pressed Retry.
Parsware Platform
A loop that never ends is a typo away, and on the server it would hold a save open forever. So every script runs on a budget. We wrote two broken plugin steps, a loop counting the wrong way and a function with no way out, and read what the platform says when it stops them.
Parsware Platform
The same solution in two environments should call two different payment services, a sandbox in one and the real thing in the other, without anybody editing a script. That's what an environment variable is for. We installed one solution in two environments, gave each its own value, and saved the same order in both.
Parsware Platform
A security role says what somebody may do with a table. A data policy says which records that reaches, and when a save is refused. We imported a sample with one of each kind, gave its role to two regional managers, and watched the same grant show each of them a different list and refuse one of them an approval.
Parsware Platform
A Custom API gives another system one address to call that keeps its shape while your tables change. We built one from nothing: the contract, the script behind it, the OpenAPI description it generates, a call from outside, and a second version answering beside the first.
For Power Apps
Everything a drawn screen does is written in BS, in a code editor inside Parsware Studio. The editor knows your Dataverse environment, so it offers your tables, then their columns, as you type, and it underlines a mistake before you save. Here is how to use it.
