The Object That Logs In on Every Call
An insurance process handles 900 policy lookups per run. The business object has a separate action for each lookup, and each action begins by launching the browser, logging in, navigating to the search page, performing the lookup, and closing the browser. A single lookup takes about 22 seconds, of which roughly 15 seconds is login and navigation. The run takes over five hours and is approaching the overnight window limit. The object was built by copying stages between actions, and the login stages differ slightly between actions: two use a 20-second wait, one uses a 60-second wait, and one has no wait at all. A recent portal change added a cookie banner that appears on first login per session.
1. Recommend a restructure of the object to reduce runtime, and explain how the cookie banner interacts with your design.
Read the worked answer
The dominant cost is repeated session setup. Fifteen of twenty-two seconds per lookup is login and navigation, so roughly 68% of runtime is overhead. The fix is to separate session lifecycle from the lookup action.
Introduce explicit actions: Open Session (launch browser, handle cookie banner, log in), Do Lookup (navigate to search, enter policy, read result), and Close Session. The process calls Open Session once, loops over the 900 policies calling Do Lookup, then calls Close Session in a cleanup block that runs even on failure.
The cookie banner appears on first login per session. With one session, it is handled once inside Open Session. Under the current design, each action launches a fresh session, so the banner appears on every lookup, and any action that does not handle it will stall or fail. That explains the inconsistent waits: the copied login stages were patched ad hoc.
Consolidating login into one action also removes the divergence between the four copies (20s, 60s, none). One place to maintain, one wait to tune. Expected runtime drops substantially because the 15-second overhead is paid once rather than 900 times.
2. What risks does the long-lived session introduce, and how should the object handle them?
Read the worked answer
A long-lived session is efficient but fragile. Risks include session timeout after inactivity, memory growth in the browser over 900 lookups, a portal deploy mid-run invalidating the session, and a single corrupted page state poisoning subsequent lookups.
Handle them with a session-health check inside Do Lookup: before each lookup, verify a known element is present. If it is missing, raise a recoverable system exception. The process-level recovery should call a Reopen Session action and retry the current policy, up to a small retry limit, then route the item to an exception queue.
Add a periodic recycle: after every 200 lookups, close and reopen the session to bound memory growth. Log the recycle so it is visible in the audit trail. Also capture a screenshot on session failure, and ensure Close Session runs in a cleanup block so a crashed run does not leave orphaned browser processes holding the session.
The design principle: optimise by reusing the session, but treat the session as a resource that can fail and must be verified, recycled, and cleaned up.