How to create RITM backend using ATF

sheetalpadole14
Tera Contributor

3 weeks ago

Hi,

how to create a manual RITM from the backend using ATF?

I need to follow this approach since the portal submission is blocked due to the Custom-type variable. 

 

0 Helpfuls
  • 237 Views
1 REPLY 1

Nayan ArchX
Giga Guru

3 weeks ago - last edited 3 weeks ago

 

You can do this in ATF without touching the portal UI by creating the REQ/RITM server-side (Cart API / sn_sc.CartJS) and then querying the created RITM in later ATF steps.

This is the most reliable approach when a custom variable type blocks portal submission.

Approach A (recommended): ATF + “Run Server Side Script” to create the RITM

Step 1 — Create an ATF Test

  • Go to Automated Test Framework > Tests

  • Create a new test (e.g., Create RITM backend – <catalog item>)

Step 2 — Impersonate the requester (important)

Add ATF step:

  • Impersonate user

    • Choose the user who should submit the request (requested_for / opened_by context)

Step 3 — Run Server Side Script (creates REQ + RITM)

Add ATF step:

  • Run Server Side Script
    Use a script like below (replace CAT_ITEM_SYS_ID and variable names/values).

This uses sn_sc.CartJS().orderNow() which is a common server-side pattern to submit a catalog item.

 

 
// ATF: Run Server Side Script // Goal: Create REQ/RITM server-side and stamp a unique marker so ATF can find it later. (function () { // 1) Unique marker so we can query the RITM later in ATF without passing variables between steps var marker = "ATF_RITM_" + gs.generateGUID(); // 2) Build the order payload var item = { sysparm_id: "CAT_ITEM_SYS_ID", // sys_id of sc_cat_item sysparm_quantity: "1", variables: { // Replace with your variable names // Example: // short_description: marker, // if you have such a variable // u_custom_var: "abc" } }; // 3) Order var cart = new sn_sc.CartJS(); var orderResult = cart.orderNow(item); // returns info including the created request (varies by version) :contentReference[oaicite:1]{index=1} // 4) Find the newly created RITM (latest for this request + item) // Some implementations return request sys_id as orderResult.sys_id; if not, query by current user/time window. var reqSysId = orderResult.sys_id || orderResult.request_id || ""; // best-effort var ritm = new GlideRecord("sc_req_item"); if (reqSysId) { ritm.addQuery("request", reqSysId); } else { // fallback: last RITM created by this user in the last few minutes for this cat item ritm.addQuery("sys_created_by", gs.getUserName()); ritm.addQuery("cat_item", "CAT_ITEM_SYS_ID"); ritm.addQuery("sys_created_on", ">=", gs.minutesAgoStart(10)); } ritm.orderByDesc("sys_created_on"); ritm.setLimit(1); ritm.query(); if (!ritm.next()) { gs.error("ATF: Could not locate created RITM. Order result: " + JSON.stringify(orderResult)); return; } // 5) Stamp a marker on the RITM so the next ATF steps can query it // Choose a field you can safely set (short_description is common). ritm.short_description = marker; ritm.update(); gs.info("ATF_MARKER=" + marker); gs.info("ATF_RITM_SYSID=" + ritm.getUniqueValue()); gs.info("ATF_RITM_NUMBER=" + ritm.number); })();
 

If you have MRVS (Multi-Row Variable Set): you usually set it as a JSON string via cart.setVariable(...) pattern (instead of plain variables:{}), like this community example.

Step 4 — Find the created RITM (Record Query)

Because ATF doesn’t always pass server-script outputs cleanly between steps, the usual trick is: stamp a unique marker (as above) and then query it.

Add ATF step:

  • Record Query

    • Table: sc_req_item

    • Condition: short_description contains ATF_RITM_ and sys_created_by is (your test user) and sys_created_on >= last X minutes

    • Order by sys_created_on desc, limit 1

(Community guidance commonly suggests querying by “created today / created by / known field value”. )

Step 5 — Open the RITM and assert downstream behavior

Add ATF steps like:

  • Open Existing Record (use output of Record Query)

  • Assert Field Values

  • If your flow creates tasks/approvals:

    • Record Query on sc_task where request_item = <RITM>

    • Assert count/state/assignment group, etc.

Approach B (if you only need to test fulfillment, not ordering): “Replay Request Item”

If your real goal is to test the post-ordering process (approvals/tasks/flow), ATF has a Replay Request Item concept where you replay an existing RITM to test the ordering process once a request exists.
This avoids portal ordering entirely—but you’ll need a seed RITM in the system.

Why this works for your situation

  • Your portal submission is blocked due to the custom variable type (UI / portal behavior).

  • Creating the request via server-side Cart API bypasses the portal UI layer and is a standard automation technique for catalog ordering.

Quick checklist / common pitfalls

  • Run as a user who has permission to order that catalog item.

  • Ensure required variables are set (otherwise the item might submit but fail downstream).

  • If your custom variable type drives mandatory logic, replicate that logic by setting the equivalent backend values.

  • If orderResult doesn’t return the request sys_id in your instance, use the fallback query method (created_by + cat_item + last 10 minutes).

 

If my response has resolved your query, please consider giving it a thumbs up ‌‌ and marking it as the correct answer‌‌!

 

Thanks

Nayan Patel

IT ServiceNow Consult, ServiceNow ArchX

If my response has resolved your query, please mark it Helpful by giving it a thumbs up and Accept the Solution

0 Helpfuls