Announcing ServiceNow SDK 2.2.6 is available!

[BryceG]

We are excited to announce that release 2.2.6 of the ServiceNow SDK is available on npm!

With this release we have squashed some bugs added a few utilities to make development with large strings better!

Fixes:

• Delete records for `sys_db_object` are causing errors during fetch
• Duplicate List calls are generated when lists have parents references
• Fix situation where the default sys ui view could be deleted

Changes to fetch and convert behavior!

In previous versions of the SDK, the fetch and convert commands would convert all application metadata files into the equivalent fluent (now.ts) representation. We recognize that for existing applications many users would rather convert code to fluent (now.ts) code piece by piece in order to have more control over how their app is changing, and reduce the amount of changes happening all at once.

The default behavior of 'fetch' and 'convert' commands have changed to not generate fluent code for existing application metadata by default, and instead leave these files as xml in the `metadata` folder. The xml files in metadata folder are the exact files that the instance is exporting, so there is no change to the application at the start of fluent development. During build and deploy the xml metadata files will be included in the application package along with any fluent code. If a piece of metadata has a representation in fluent and in xml, the xml representation will take precedence.

Files downloaded from the instance during fetch will respect the metadata folder and update the xml representation of the record instead of generating fluent code. If the record has no xml representation in the local metadata folder, fetch will generate it as new fluent code or update the corresponding existing fluent code.

If you wish to transition an existing app to fluent, you now have the option to scaffold the app as a fluent project and leave the records as xml in the metadata folder . This allows for iterative development and conversion into fluent on a record-by-record basis, so that applications can be converted over without potentially changing behavior all at once.  The transform command is available if you wish to convert individual pieces of metadata over into fluent during your conversion or development cycle.

[tdexter]

2 questions: 

1. How can set a reference field using the Record API when the record I want to reference is also created with Fluent SDK? 

For example, I want to create an `oauth_entity_profile` and `oauth_entity_scope` and in the scope, set the entity to the created entity. `Now.ID[<value>]` says the value will be hashed into a sys_id during build but it appears it only does that when it's used in an `$id` field. I need it to work in all fields. In the code below the `oauth_entity` field should be set to the same hashed sys_id of the `oauth_entity` record created above it but in the `dist/update/oauth_entity_profile_SYSID.xml` the `oauth_entity` field is simply set to the string value "MyOAuth" which means no connection is made back to the record. 

Record({
    $id: Now.ID['MyOAuth'],
    table: 'oauth_entity',
    data: { // oauth data ... }
})

Record({
    $id: Now.ID['MyOAuthProfile'],
    table: 'oauth_entity_profile',
    data: {
        name: 'Default Profile',
        oauth_entity: Now.ID['MyOAuth'],
        grant_type: 'client_credentials',
        default: true,
    }
})

Record({
    $id: Now.ID['MyOAuthEntityScope'],
    table: 'oauth_entity_scope',
    data: {
        name: 'OAuth Default Scope',
        oauth_entity: Now.ID['MyOAuthProfile'],
        oauth_entity_scope: 'api://my-api/.default',
    }
})

 
Question 2: 

I love that you included the Now.include('path/to/file.html') syntax - that is great for string fields expecting scripts or other strings. What I really need is something like `Now.file('path/to/file.png')` which actually uploads the file to sys_attachment and then links it via a `File` field type. Is that on the roadmap? 

[tdexter]

I've taken a look at the source code for Record and figured out question 1 above. 

You can get access to the entity created by storing the return in a variable and then use that in further created records, ie: 

const oauth = Record({
    $id: Now.ID['MyOAuth'],
    table: 'oauth_entity',
    data: { // oauth data ... }
})

const profile = Record({
    $id: Now.ID['MyOAuthProfile'],
    table: 'oauth_entity_profile',
    data: {
        name: 'Default Profile',
        oauth_entity: oauth.$id,
        grant_type: 'client_credentials',
        default: true,
    }
})

Record({
    $id: Now.ID['MyOAuthEntityScope'],
    table: 'oauth_entity_scope',
    data: {
        name: 'OAuth Default Scope',
        oauth_entity: profile.$id,
        oauth_entity_scope: 'api://my-api/.default',
    }
})

[BryceG]

@tdexter 
1) You should be able to use a reference to that entity in the 2nd call like a variable

const oauthEntity = Record({
    $id: Now.ID['MyOAuth'],
    table: 'oauth_entity',
    data: { // oauth data ... }
})

const oauthProfile = Record({
    $id: Now.ID['MyOAuthProfile'],
    table: 'oauth_entity_profile',
    data: {
        name: 'Default Profile',
        oauth_entity: oauthEntity,
        grant_type: 'client_credentials',
        default: true,
    }
})

Record({
    $id: Now.ID['MyOAuthEntityScope'],
    table: 'oauth_entity_scope',
    data: {
        name: 'OAuth Default Scope',
        oauth_entity: oauthEntityProfile,
        oauth_entity_scope: 'api://my-api/.default',
    }
})

2) Its on the roadmap and coming soon, as attachment and binary data handling for the platform is different than just putting some string content into a field.  Expect it soon though!

[tdexter]

@BryceG yes, I was actually able to do it like `oauthEntity.$id` - maybe just putting the whole record in there would work too. I posted back with this solution but it's awaiting approval. 

[tdexter]

@BryceG is there somewhere we can see the roadmap and/or post feedback, issues, etc... I couldn't find a github repo for it.