Skip navigation

Remedy OnDemand

7 Posts authored by: Poppi Turlich Employee
Share:|

Digital transformation is a phrase that you may have heard numerous times over the past year and perhaps it has sparked your interest.  Do you find yourself asking, “What does this really mean?” If terms like “Monolithic Architecture”, “Microservices” and “Containerization” have your head spinning – don’t worry, you are not alone. Let’s break these concepts down one by one and talk about what they mean for you as a BMC Helix Customer.

 

Here’s the skinny for you techies:

 

When you think about Monolithic Architecture, think about a traditional “enterprise application” - you have a database, an application running on a server somewhere, and a client-side user interface (often accessed via a browser). It is a monolith – one large, single pillar or executable. To add functionality to your application, an updated version of the entire application must be deployed on the server. In today’s DevOps world, you can compare this to Stonehenge.

 

Now enter stage left - Microservices and Containers…

 

Microservices are easy to explain. They are essentially a subcomponent of that “enterprise application” - think Smart IT, RSSO, Smart Reporting, etc. Containers (a little more complicated), wrap these microservices. You may have heard that Containers are the next evolution of Virtual Machines (VM’s), but the truth is they can (and often do) coexist. Containers decouple the application from the OS and are platform independent. They package independent components of an “enterprise application” and are designed to be lightweight, consuming the OS of their host. They can run anywhere! Multiple containers can be deployed in a single VM, but they can also be deployed directly on the underlying infrastructure.

 

Now that we have the more technical details out of the way, WHAT DOES THIS MEAN FOR YOUR BUSINESS?

  1. Containers are agile; they can quickly be deployed. As new functionality becomes available, these innovations can be deployed to your business users rapidly. You can easily adopt new releases and no longer need to set aside valuable resource time for an extended upgrade project.
  2. Containers scale to fit your needs. With the help of tools like Kubernetes, if you need more resources (or less), we can quickly add (or remove) them with no impact to your business.
  3. Containers can be deployed in our BMC Cloud or in public clouds (such as AWS or AZURE) enabling us to offer our service in the cloud of your choice, helping you align your enterprise solutions with your corporate cloud strategy.

 

Here is the bottom line: MORE agility, MORE scalability and MORE flexibility for what matters most to your business. Sounds pretty transformative to me!

 

If you’d like more information regarding any of these terms we’ve covered here or what BMC Helix means to you, please reach out your Business Relationship Manager.

 

Share:|

Bringing you value is a priority for BMC. In order to ensure that our BMC Business Relationship Management Team is concentrating on the right things to bring you the most value from Remedy as a Service, we are distributing a brief survey. The survey asks key questions about your experience today and what you’d like it to be in the future.

 

We would appreciate it if you’d watch your email in the coming days for a survey entitled “SaaS Quarterly BRM Value Survey” from saassuccess@bmc.com and provide us your totally candid feedback. In order to receive the survey and help ensure we bring the greatest value to your organization, it is important that you have opted in to communications. If you are not sure if you have opted-in, please reach out to your Business Relationship Manager.

 

We are planning a number of improvements to our working model and your input into that is important to us. This survey, as well as other feedback we’ve received during Service Reviews and other regular interactions, will drive our priorities and help reshape the BRM role to bring you the most value. As part of this process, we want you to know how your feedback will be driving our improvements, so after the survey has concluded we will be sharing both the results and our plans.

 

If you have any questions about the survey or the survey process, please feel free to post them here or reach out to your Business Relationship Manager.  Thanks so much in advance for your participation!

Share:|

Periodically you may wish to refresh your DEV or QA ITSM databases with Production data. There is no best practice as to how often this should be done, as it is determined by the development life cycle of your organization. A good rule of thumb would be to ensure lower environments are refreshed quarterly to biannually, depending on how active your development is, as this helps make certain they remain in sync with production. Lower environments are also refreshed as part of many upgrade projects. There are some several best practices/things that you should consider when you decide you are ready for a refresh.

 

Best practice considerations include:

  1. Are you in the process of or do you have an upcoming scheduled upgrade? Both the source (typically production) and the target (QA or DEV) must be at the same version and patch level to do a refresh. Additionally, databases are refreshed as part of most upgrades. If you have a question about if the environment will be refreshed as part of a scheduled upgrade, please reach out to your Business Relationship Manager or upgrade Project Manager.
  2. Do you have any data jobs that have hard-coded hostname, IP’s, etc? Any hard-coded values need to be updated to reflect valid target system values post-refresh.
  3. Do you have customizations or development that hasn’t been promoted from target (i.e. DEV) to source (Production)? If so, these need to be manually backed up using Developer Studio, the Deployment Management Console, Spoon Client, or other tools. Changes to Approval, Entitlement, Assignment and Application configurations in target system should be promoted to Production or documented by the customer prior to a refresh or they will be overwritten.
  4. Do you have any scheduled jobs or other changes requested during the refresh window? No other activity should be scheduled during the refresh window.

 

During a refresh, the source environment (i.e. Production) is not impacted. The outage for the target environment depends on the size of the system, but typically require a 4-5 hour window where the target system will be unavailable during the week. It is recommended that customers do not attempt to access their target environment, even if it appears available, until they receive a message from the RaaS Change team that it is ready. This is because of additional configuration changes that may still be going on.

 

What is NOT included in a refresh:

  1. Smart Reporting is NOT included in a standard RaaS Refresh. Reports in the target environment will not be impacted by the refresh. A Smart Reporting refresh can be done, though it is not recommended (This is because org name cannot be changed, resulting in source and target having the same name). Smart Reporting refreshes should be handled as a separate Change Request and only after limitations are fully understood.
  2. Integration hard-coded configurations are not included by default. (Any hard-coded IP addresses, host names, and/or URL's in UDM jobs,web services, etc. need to be specifically identified by the customer before the refresh so that changes can be made to the target system. If these are not identified, integrations in the database will be refreshed as is, and values from target will be overwritten with values from source.)
  3. Other server level changes (i.e. config files) are not included
  4. Database backups (if you want your database backed up prior to a refresh, it needs to be specifically requested in the CRQ)

 

When you are ready to move forward with a refresh, here are some items that you will want to ensure:

  1. The CRQ should be raised at least 1 week prior to the requested date of the refresh
  2. A separate CRQ is required for each refresh (if you want both DEV and QA refreshed, it requires 2 CRQ’s)
  3. The CRQ has the source and the target URL. For example, restore from https://xxxxxx.onbmc.com to https://xxxxxx-dev.onbmc.com
  4. Explicitly include any special instructions for before or after the restore in the CRQ, for example:
    1. Turn off email service in source after refresh (if this is not specified, target will match source and can result in inadvertent emails being sent)
    2. Clear AR System Email Messages (if this is not specific, cleared emails in target may be triggered to users after refresh)
    3. Ensure RSSO branding is restored on DEV post upgrade
    4. Update web service y URL to xxx after refresh
  5. If you have questions about something specific to your environment, include those questions in the CRQ.

 

Once the refresh is complete, it is recommended that you test the basic functionality of the refreshed system (i.e. logging a ticket via ITSM, Smart IT, and Digital Workplace). If you have integrations or DMT jobs in the target system, these should also be validated. You may also want to restart any paused jobs. If you have any issues with any of these or anything else believed to be related to the refresh, raise a request via i.onbmc.com. If you have questions about the Refresh process, please reach out to your Business Relationship Manager.

Share:|

The highly anticipated Smart IT 2.0 is now available for Remedy as a Service (RaaS) customers. Some of the new Smart IT 2.0 capabilities available to administrators include the ability to:

 

  • Change the layout of the Incident and Change forms, placing custom fields wherever they are needed, moving existing fields, and hiding any out-of-box fields which are not required.
  • Dynamically control the key properties of fields (hidden/visible; read-write/read-only; mandatory/optional), and set data to fields, using logical expressions which execute in real-time as the user works on a record (even on mobile!).
  • Add custom fields to the ticket console, and filter records using them.
  • Take advantage of a significantly enhanced "provider action" capability, enabling server-side workflow actions to run in the Smart IT client, and creating icons alongside fields on the form to run them.

 

A couple capabilities (primarily related to Cognitive Service Management and the Remedy Deployment Application (D2P)) require Remedy AR Platform to be on 9.1.04. Otherwise, Remedy ITSM 9.1.00 is the minimum supported version for Smart IT 2.0.  Smart IT 2.0 is coupled with Digital Workplace (DWP) 18.02 during installation. Digital Workplace 18.02 replaces the previous 3.5 version.

 

 

For good reason, there is lots of buzz around the enhanced capabilities of Smart IT 2.0 and Digital Workplace’s continued focus on improving the end user experience, as well as its Integration Services. There are many resources available to you on communities.bmc.com and docs.bmc.com  (including the opportunity for you to post your own questions). Please see below for a consolidated list of just a few of the Smart IT 2.0/Digital Workplace 18.02 blogs/resources available to you right now:

 

 

To get more information on upgrading to Smart IT 2.0/Digital Workplace 18.02 or how to use our BMC Communities and Docs pages, please reach out to your Business Relationship Manager.

Share:|

With the end of life of Analytics, several customers have inquired about various reporting and data access requirements. Released in 9.0, Smart Reporting is the next generation BMC Remedy IT Service Management Reporting and Analytics solution. It is a web-based, in-app, intuitive solution that provides an easy to use, drag and drop interface for rapid report development. Occasionally, Remedy as a Service (RaaS) customers have additional requirements for reporting/data access which BMC accommodates by offering access to the Remedy ITSM database layer, via Open Database connectivity, or ODBC. ODBC is an open standard Application Programming Interface (API) for accessing a database. It permits applications to use SQL to access the database, without having to know the details of the database system. ODBC handles the SQL request, converting it to a request that each system understands. ODBC allows customers with unique data requirements access to their data. Some examples of where an ODBC connection might be utilized include:

 

  • Extracting data from Remedy as a Service (RaaS) for an in-house data warehouse/data store
  • Executing SQL against Remedy as a Service (RaaS) to generate a .csv file to build a report/chart in Excel, Analytics tool, or other application
  • Utilizing an in-house reporting solution (i.e. Crystal Reports, Business Objects, etc.) against the Remedy as a Service (RaaS) database

 

The ODBC connection provides read access to the database layer, including the ability to read the schema model (tables, views, fields and data types, constraints, query plans, etc.). The Remedy data model is complex and an understanding of the data model, table joins, and proper data type mapping is important. If SQL reporting writing/data warehousing experience doesn't exist internally in your organization, BMC Professional Services can be utilized to assist with this development.

 

The only prerequisites for ODBC connectivity are a client gateway and that the appropriate data access driver be installed on the client that will be connecting via ODBC. Once ODBC access to the RaaS environment is requested and appropriate information is collected, credentials (a user name and password) for connectivity will be provided to the requestor.

 

FAQ:

  • A Client Gateway must be set up to utilize ODBC (can use an existing Client Gateway if it is already set up for other RaaS integrations). For more information client gateway, please see: BMC Client Gateway connectivity - BMC Remedy OnDemand Subscriber Information - BMC Documentation
  • A separate ODBC request is required for each RaaS environment
  • Upgrades and Customizations can impact the database, therefore may impact your queries/reports and will require redesign/development accordingly
  • The current Remedy as a Service database is Microsoft SQL Server 2012. Upgrades to new versions of SQL Server can impact the database, therefore may impact your in-house queries/reports/data warehouse/date stores and will require redesign/development accordingly.

 

Best Practices:

  • Development of SQL queries, Reports and/or any other data extract processes should not be done against the RaaS Production database. Customers should set up an ODBC connection to each environment (DEV, QA, and Production) and make sure to perform development and testing in lower environments before running anything against Production.
  • Any large SQL statements and/or reports with large datasets should be run during non-peak hours. Basically, there is a balance between performance and reporting. Though we govern the resources that are allowed to be allocated to reporting, large or poorly written SQL can impact application performance.

 

Limitations:

  • Remedy as a Service (RaaS) does not support stored procedures, functions, or design level database customizations in the RaaS database.
  • Customers are allowed 1 ODBC user/connection per environment. If multiple levels of data access are required, it should be implemented through your own access control methods, via your warehouse/analytics applications or through reporting tool access.

 

To Request Access:

 

  • Login into i.onbmc.com and "Request Something Else" and use "ODBC connection setup" as the Summary.
  • Attach an ODBC Access Request Form

 

Note: Client Gateway setup can also be requested by going to i.onbmc.com and "Request Something Else" and use "Client Gateway setup" as the Summary.

Share:|

Do you find yourself confused about what gets done during Remedy On Demand monthly maintenance windows or what the difference is between a patch and service pack? If so, you are not alone.  Before we get started understanding the difference between maintenance, hotfixes, patches and service packs, it is important to remember that Remedy OnDemand is simply a BMC hosted instance of Remedy ITSM. There are not OnDemand specific hotfixes, patches, and service packs. These are each related to the product being hosted, i.e. Remedy ITSM, MyIT, etc.

 

To get started, let’s take a look at OnDemand monthly maintenance. Planned maintenance typically occurs on a monthly schedule to address firmware, server, OS, driver, and infrastructure application patches. These patches are applied to non-production and production environments on separate dates within the month, typically 2 weeks apart. These date will vary for customers depending on their region. Monthly maintenance does NOT cover Remedy, MyIT, or other BMC product-specific patching. Maintenance reminders are sent out in advance of the next month's maintenance and contain information on the activity being performed, the downtime/service impacted, and the scheduled date and time. Though BMC makes every attempt to avoid it, occasionally emergency maintenance is required. In such cases, notifications are sent out at the earliest possible point. Notifications are also sent to customers at the start and completion of each maintenance activity. For more information on RoD maintenance, please refer to https://docs.bmc.com/docs/display/rondsubscriber/Maintenance+windows. If you are not receiving maintenance notifications, please contact your Business Relationship Manager.

 

A hotfix is a single or cumulative package that is engineered to address a product problem, typically for a specific customer situation. These are only available through the customer support organization and are not publicly available. These are typically not applied proactively to other customer environments, as each customer is unique with unique and varied customization's.

 

Product Patches, which are made up of multiple hotfixes, are released monthly to address known issues within a product. Available Remedy ITSM and other product patches can be viewed by logging into www.bmc.com/support and going to Product Downloads. If you want to be alerted when new patches are released, you can sign up for alerts on the same support page by going to My Support > Product Alerts. From there, you can select which types of notifications you would like to receive. To request the application of a specific product patch to your environment, go to i.onbmc.com and select “Request Something Else”. Please ensure you specify the product, patch number and the appropriate environment in your request.

 

Service Packs are released quarterly to semiannually and include a rollup of the all previously released patches, as well as improved or new functionality. Release notes for Service Packs can be found on docs.bmc.com by searching under the applicable product. Service Packs are applied to customer environments as a project and can be scheduled through your Business Relationship Manager.

 

For more information on any of the above, please reach out to your Remedy OnDemand Business Relationship Manager.

Share:|

Are you a developer or administrator looking for more control in migrating your customizations in your Remedy OnDemand environments? If so, a great utility is now available to Remedy OnDemand Administrators and Developers who are at Remedy 9 or higher. The utility, the AR System Deployment Management Console, or D2P (slang for Dev to Prod) as it is commonly referred, provides an effortless interface to promote workflow customizations across environments (Development, QA, and Production). This includes the promotion of both new and modified Service Request Definitions. D2P provides a simple method that consumes less time and increases your control of code promotions.

 

The process to build and migrate packages contains 5 quick and straightforward steps:

  1. CREATE
  2. BUILD (and validate)
  3. EXPORT
  4. IMPORT
  5. DEPLOY

 

To get to the D2P utility, you need to be an administrator and log on to a BMC AR System Server, go to the AR System Administration tab, and then to the AR System Deployment Management Console.

 

When you create a package, it allows you to search and select the objects that will be included in the package. You can use this utility to migrate both data and definitions.  Examples of definitions that can be included in D2P packages are:

  • Form
  • Filter
  • Active Link
  • Menu
  • Escalation
  • Container
  • Application
  • Image
  • Associations

 

As mentioned previously, the steps are very easy and consist of the following:

 

CREATE: This function allows you to add definitions to your package. The names of your definition items must match how they are entered in Developer Studio.  There is a sequence field that is auto populated as you add contents to the package and is used to determine the sequence in which package items are built, validated and deployed. Once you have created the package, it will show up in your list with a status of “Draft”.

 

BUILD: When you select “Build”, your package is validated and compiled for use. After the package is built, it will have a status of “Ready to Deploy”, and is ready for use. Note: You may need to refresh your browser to see the updated status.  If there is an error during validation/compilation, the reason for the error will be displayed in the Status field and the state will return to “Draft”.

 

EXPORT: Exporting the package creates a zip file that gets downloaded to your computer with all relevant files included.

 

IMPORT: To import the file, you would then log onto a BMC AR System Server in the appropriate environment and maneuver again to the AR System Deployment Management Console. Select Import and select the zip file exported from the previous server. Once imported, the package will show a status of “Ready to Deploy”. NOTE: If you are making changes to existing workflow, it is a BEST PRACTICE to back up existing files by exporting them before you import anything new.

 

DEPLOY: Select the imported package and Select “Deploy”.

 

Utilizing the AR System Deployment Management Console, Dev to Prod (D2P) promotion is streamlined with best practices for code promotion in mind. With straightforward packaging, each set of objects promoted is clearly defined for developers and admins who come behind you, version control is simple to manage, and everything is consolidated in a single easy to use interface. Simply put, D2P allows you to work effectively and reliably across all platforms, all while saving you valuable time.

Filter Blog

By date:
By tag: